[B.A.T.M.A.N.] Batman an more than one Gateway

[B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 2988 bytes --]

Hello,

I have take a look to the configuration of our gateways.
Inho there are some points which are not OK,
Broadcasts are rebroadecasted on a wired connection,
this seem for me to be an issue.

Our network has two gw which are interconnected.
I have listed the interfaces and the output from
batctl on the GW and also what batxtl said on a node

=================================================================

 Interfaces for gateway Q0:
 br0:	         12:e8:ef:7f:0d:c7
  bat0:          12:e8:ef:7f:0d:c9
   ftun-q1:      12:e8:ef:7f:0d:c8
   mesh-vpn:     aa:ff:ca:ca:fe:03

-------------------
# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2014.3.0, MainIF/MAC: ftun-q1/12:e8:ef:7f:0d:c8 (bat0)]
   ca:b1:f2:63:f3:cf (251) ca:b1:f2:63:f3:cf [   ftun-q1]: 50.0/50.0 MBit

--------------------------------------
On node (connected with Q0):

# batctl n
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1 (bat0/90:f6:52:11:44:f1 BATMAN_IV)]
IF             Neighbor              last-seen
     mesh-vpn	  aa:ff:ca:ca:fe:03    3.342s

---------------------
# batctl gwl
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1 (bat0/90:f6:52:11:44:f1 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
* ca:b1:f2:63:f3:cf (240) aa:ff:ca:ca:fe:03 [  mesh-vpn]: 50.0/50.0 MBit
  12:e8:ef:7f:0d:c8 (255) aa:ff:ca:ca:fe:03 [  mesh-vpn]: 50.0/50.0 MBit

Translated Interface/Location
   ftun-q1/Q0       (255) mesh-vpn/Q0
*  ftun-q0/Q1       (240) mesh-vpn/Q0

=================================================================

Interfaces for gateway Q1:
 br0:	         ca:b1:f2:63:f3:cd
  bat0:          ca:b1:f2:63:f3:cd
   ftun-q0:      ca:b1:f2:63:f3:cf
   mesh-vpn:     aa:ff:ca:ca:fe:01

---------------------
# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2014.3.0, MainIF/MAC: ftun-q0/ca:b1:f2:63:f3:cf (bat0)]
   12:e8:ef:7f:0d:c8 (255) 12:e8:ef:7f:0d:c8 [   ftun-q0]: 50.0/50.0 MBit

--------------------------------------
On node (connected with Q1):

# batctl n
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1 (bat0/90:f6:52:11:44:f1 BATMAN_IV)]
IF             Neighbor              last-seen
     mesh-vpn	  aa:ff:ca:ca:fe:01    4.413s

---------------------
# batctl gwl
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1 (bat0/90:f6:52:11:44:f1 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  ca:b1:f2:63:f3:cf (255) aa:ff:ca:ca:fe:01 [  mesh-vpn]: 50.0/50.0 MBit
* 12:e8:ef:7f:0d:c8 (240) aa:ff:ca:ca:fe:01 [  mesh-vpn]: 50.0/50.0 MBit

Translated Interface/Location
   ftun-q0/Q1       (255) mesh-vpn/Q1
*  ftun-q1/Q0       (240) mesh-vpn/Q1

===================================================================

Regards,

Jean-Jacques


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Marek Lindner]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Hi,

> I have take a look to the configuration of our gateways.
> Inho there are some points which are not OK,
> Broadcasts are rebroadecasted on a wired connection,

please note that batman's payload reboradcast behavior is unrelated to the 
batman gateway feature. The effect of the batman gateway feature is explained 
here: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways

Rebroadcast on an interface depends on the interface type. Generally, batman 
runs on 3 different types of interfaces:

 * WiFi: payload broadcasts are transmitted 3 times to increase the chances of 
a successful transmission
 * VPN / wired Ethernet: payload broadcast is transmitted once as most sane 
VPNs don't experience packet loss

Guessing from your interface names you are running VPNs and not wired 
Ethernet, is that correct ?


> this seem for me to be an issue.

What exactly is the issue ? 


>       Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink
> bandwidth ... [B.A.T.M.A.N. adv 2014.3.0, MainIF/MAC:
> ftun-q1/12:e8:ef:7f:0d:c8 (bat0)] ca:b1:f2:63:f3:cf (251) ca:b1:f2:63:f3:cf
> [   ftun-q1]: 50.0/50.0 MBit
> 
> [B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1
> (bat0/90:f6:52:11:44:f1 BATMAN_IV)] IF             Neighbor             
> last-seen
>      mesh-vpn	  aa:ff:ca:ca:fe:03    3.342s

It is recommended to run the same batman version on all nodes to avoid 
unexpected behavior. These 2 versions are separated by 2 years of development.


Cheers,
Marek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 3402 bytes --]

Hi Marek,


Am 05.11.2016 um 04:14 schrieb Marek Lindner:
> Hi,
> 
>> I have take a look to the configuration of our gateways.
>> Inho there are some points which are not OK,
>> Broadcasts are rebroadecasted on a wired connection,
> 
> please note that batman's payload reboradcast behavior is unrelated to the 
> batman gateway feature. The effect of the batman gateway feature is explained 
> here: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
> 
This seem to work but for IPv6 there is nothing and the client get
RA's from all GW.

> Rebroadcast on an interface depends on the interface type. Generally, batman 
> runs on 3 different types of interfaces:
> 
>  * WiFi: payload broadcasts are transmitted 3 times to increase the chances of 
> a successful transmission
This wjat not the case, no WIFI connection or neighbors
>  * VPN / wired Ethernet: payload broadcast is transmitted once as most sane 
> VPNs don't experience packet loss

This what the interface type used. This mean that the gateway send
a broadcast via wire and the node get it as if there where no VPN between
GW and node. rebroadcasting is not OK here.

> Guessing from your interface names you are running VPNs and not wired 
> Ethernet, is that correct ?
see above

>> this seem for me to be an issue.
> 
> What exactly is the issue ? 

A good question. If all node act in the same maner we will get
a lot of traffic which must be received ny the gateway.
> 
>>       Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink
>> bandwidth ... [B.A.T.M.A.N. adv 2014.3.0, MainIF/MAC:
>> ftun-q1/12:e8:ef:7f:0d:c8 (bat0)] ca:b1:f2:63:f3:cf (251) ca:b1:f2:63:f3:cf
>> [   ftun-q1]: 50.0/50.0 MBit
>>
>> [B.A.T.M.A.N. adv 2016.4, MainIF/MAC: mesh0/92:fb:53:11:44:f1
>> (bat0/90:f6:52:11:44:f1 BATMAN_IV)] IF             Neighbor             
>> last-seen
>>      mesh-vpn	  aa:ff:ca:ca:fe:03    3.342s
> 
> It is recommended to run the same batman version on all nodes to avoid 
> unexpected behavior. These 2 versions are separated by 2 years of development.

I agree the version on the GW and the node shall be the same.
On the other hand the older version and the version I used use the
same protocol so that I expect not problem.

I have made check with a Freifunk router and on the same time with
my network space router.
All router used what connected to the same GW. I have seen
rebroadcast on both router attached to the PC which what
configured as router for 2 different subnets.
On the Freifunk router there what less rebroadcasting.
The command batctl gwl shown an othter preferred gateway. This
may explain the differences in the number of rebroadcasting.

On a Gluon Freifunk node conneted to Q1:

# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2015.1, MainIF/MAC: mesh-vpn/16:d0:20:41:5a:72 (bat0)]
   12:e8:ef:7f:0d:c8 (238) aa:ff:ca:ca:fe:01 [  mesh-vpn]: 50.0/50.0 MBit
=> ca:b1:f2:63:f3:cf (255) aa:ff:ca:ca:fe:01 [  mesh-vpn]: 50.0/50.0 MBit

Translated Interface/Location
   ftun-q1/Q0        (238) mesh-vpn/Q1       [  mesh-vpn]: 50.0/50.0 MBit
=> ftun-q0/Q1        (255) mesh-vpn/Q1       [  mesh-vpn]: 50.0/50.0 MBit

I know the batman version on the FFF router is not so old as
the GW version.

Cheer,

Jean-Jacques


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Samstag, 5. November 2016 22:29:19 CET Jean-Jacques Sarton wrote:
> Am 05.11.2016 um 04:14 schrieb Marek Lindner:
> > Hi,
> > 
> >> I have take a look to the configuration of our gateways.
> >> Inho there are some points which are not OK,
> >> Broadcasts are rebroadecasted on a wired connection,
> > 
> > please note that batman's payload reboradcast behavior is unrelated to the 
> > batman gateway feature. The effect of the batman gateway feature is explained 
> > here: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
> > 
> This seem to work but for IPv6 there is nothing and the client get
> RA's from all GW.

The important message from Marek (we already told you this multiple
times) was:

"batman-adv gateway feature" has nothing to do with "rebroadcast".

So please stop mixing these things together in all your messages. It also
doesn't help when you now start to bring up IPv6 RAs. They are not IPv4
DHCP requests and are therefore as unrelated to the "batman-adv gateway
feature" as "rebroadcasts".

> > * VPN / wired Ethernet: payload broadcast is transmitted once as most sane 
> > VPNs don't experience packet loss
> 
> This what the interface type used. This mean that the gateway send
> a broadcast via wire and the node get it as if there where no VPN between
> GW and node. rebroadcasting is not OK here.

This can be wrong (as explained in my last mail). Gluon only sets the
no_rebroadcast on the Freifunk router because it doesn't have to handle
distribution of broadcast to multiple fastd endpoints. It would be
completely wrong when set on the fastd server (handling multiple clients).
See my other mail for details.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Linus Lüssing]

On Sat, Nov 05, 2016 at 11:25:38PM +0100, Sven Eckelmann wrote:
> This can be wrong (as explained in my last mail). Gluon only sets the
> no_rebroadcast on the Freifunk router because it doesn't have to handle
> distribution of broadcast to multiple fastd endpoints. It would be
> completely wrong when set on the fastd server (handling multiple clients).
> See my other mail for details.

Just as a small addition, I think I've said it in the ticket, too:
Jean-Jacques, in one point, you're absolutely right:

When there is just one neighbor on an interface, then rebroadcasts
can easily be avoided. Which is the case in your scenario on the
VPN client(!) side.

Gluon has this extra patch for batman-adv, this no_rebroadcast
knob. But an automatic detection which should cover this specific
VPN client case, was merged into upstream batman-adv just a few
days ago \o/ :).


For any case with more than one neighbor on an interface it is
very hard to detect whether upon receiving a broadcast all other
neighbors have received this broadcast too.

If we can't say for sure, then we unfortunately need to stay safe
and rebroadcast to avoid horrible packet loss / broken connections /
armageddon.

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 2838 bytes --]

Hallo Linus,

I must think about the need of rebroadcast. I agree
that message may be lost. The tcp/ip stack has the
charge of resolving such problems. For udp the partner
may accept packet loss, for example streaming of video
or sound, or have an own protocol for resolving this.

The layer 2 broadcast message are normally important and
sending occur as event. The frame may be lost. If the lost
is on the originator, nobody will become a message.
The packet lost may occur far from the originator an one or
more participant may not get the frame. If all systems are
in the wifi mesh network (each has neighbor with different
connection to the internet), forwarding shall allow
that the frame arrive via the wifi mesh devices. For
system which has no neighbor, the possibility of packet
lost is much greater and only broadcasting more time
may resolve the problem. Sending a broadcast back
can only considered as an acknowledgement. If there
are not more "acknowledgement" as known systems
(gw + node) some participant should not have got
the frame and the originator has to send the broadcast
again.

If I have a look to the clients connected via
wifi on a node broadcasts originated by the client
must not reach the node, but I have not notified
problems due to lost of ARP and so on. The only think
I can see is a lot of arp an rs mainly from smartphones.

There are probably a lot of thinks I have not understood
regardinh the mesh network.

Regards,

Jean-Jacques

Am 06.11.2016 um 18:50 schrieb Linus Lüssing:
> On Sat, Nov 05, 2016 at 11:25:38PM +0100, Sven Eckelmann wrote:
>> This can be wrong (as explained in my last mail). Gluon only sets the
>> no_rebroadcast on the Freifunk router because it doesn't have to handle
>> distribution of broadcast to multiple fastd endpoints. It would be
>> completely wrong when set on the fastd server (handling multiple clients).
>> See my other mail for details.
> 
> Just as a small addition, I think I've said it in the ticket, too:
> Jean-Jacques, in one point, you're absolutely right:
> 
> When there is just one neighbor on an interface, then rebroadcasts
> can easily be avoided. Which is the case in your scenario on the
> VPN client(!) side.
> 
> Gluon has this extra patch for batman-adv, this no_rebroadcast
> knob. But an automatic detection which should cover this specific
> VPN client case, was merged into upstream batman-adv just a few
> days ago \o/ :).
> 
> 
> For any case with more than one neighbor on an interface it is
> very hard to detect whether upon receiving a broadcast all other
> neighbors have received this broadcast too.
> 
> If we can't say for sure, then we unfortunately need to stay safe
> and rebroadcast to avoid horrible packet loss / broken connections /
> armageddon.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 1943 bytes --]

Hallo Linusm

Soll ich es auf Französich schreoben ?
Am 06.11.2016 um 18:50 schrieb Linus Lüssing:
> On Sat, Nov 05, 2016 at 11:25:38PM +0100, Sven Eckelmann wrote:
>> This can be wrong (as explained in my last mail). Gluon only sets the
>> no_rebroadcast on the Freifunk router because it doesn't have to handle
>> distribution of broadcast to multiple fastd endpoints. It would be
>> completely wrong when set on the fastd server (handling multiple clients).
>> See my other mail for details.
> 
> Just as a small addition, I think I've said it in the ticket, too:
> Jean-Jacques, in one point, you're absolutely right:
> 
> When there is just one neighbor on an interface, then rebroadcasts
> can easily be avoided. Which is the case in your scenario on the
> VPN client(!) side.
> 
> Gluon has this extra patch for batman-adv, this no_rebroadcast
> knob. But an automatic detection which should cover this specific
> VPN client case, was merged into upstream batman-adv just a few
> days ago \o/ :).
> 
> 
> For any case with more than one neighbor on an interface it is
> very hard to detect whether upon receiving a broadcast all other
> neighbors have received this broadcast too.
> 
OK with my previous mail I have wrote about my impressions.

I more as an neighbor is connected to an interface, you can not
be sure that all neighbor have received the broadcast.
Waiting and counting the rebroadcasts may be a solution but
rebroadcasting can be replaced by an acknowledgment frame.
If I have 3 node a b and c b will see a and c but a and c
may be to far from each other so that the rebroadcast from a
will not reach c until b repeat the broadcast which will
be rebroadcasted,...


> If we can't say for sure, then we unfortunately need to stay safe
> and rebroadcast to avoid horrible packet loss / broken connections /
> armageddon.
> 
Holzhammer Methode ?

Grüße,

Jean-Jacques


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

On Monday, November 7, 2016 11:03:02 PM CET Jean-Jacques Sarton wrote:
> Hallo Linusm
> 
> Soll ich es auf Französich schreoben ?
> 

We should stick to english here.

Thanks,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 2859 bytes --]

Hi,

OK I have understood that rebroadcast are necessary on some
conditions.

Am 05.11.2016 um 23:25 schrieb Sven Eckelmann:
> On Samstag, 5. November 2016 22:29:19 CET Jean-Jacques Sarton wrote:
>> Am 05.11.2016 um 04:14 schrieb Marek Lindner:
>>> Hi,
>>>
>>>> I have take a look to the configuration of our gateways.
>>>> Inho there are some points which are not OK,
>>>> Broadcasts are rebroadecasted on a wired connection,
>>>
>>> please note that batman's payload reboradcast behavior is unrelated to the 
>>> batman gateway feature. The effect of the batman gateway feature is explained 
>>> here: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
>>>
>> This seem to work but for IPv6 there is nothing and the client get
>> RA's from all GW.
> 
> The important message from Marek (we already told you this multiple
> times) was:
> 
> "batman-adv gateway feature" has nothing to do with "rebroadcast".
> 
> So please stop mixing these things together in all your messages. It also
> doesn't help when you now start to bring up IPv6 RAs. They are not IPv4
> DHCP requests and are therefore as unrelated to the "batman-adv gateway
> feature" as "rebroadcasts".

I never told that the gateway feature har to do anythings with the
gateway mode.

Examining RA/RS is a little bit easier as examinih ARP. RA are only
generated by the gateways, RS only from the clients and node. ARP
are originated from any participant within the network.

But I will not continue with this.

>>> * VPN / wired Ethernet: payload broadcast is transmitted once as most sane 
>>> VPNs don't experience packet loss
>>
>> This what the interface type used. This mean that the gateway send
>> a broadcast via wire and the node get it as if there where no VPN between
>> GW and node. rebroadcasting is not OK here.
> 
> This can be wrong (as explained in my last mail). Gluon only sets the
> no_rebroadcast on the Freifunk router because it doesn't have to handle
> distribution of broadcast to multiple fastd endpoints. It would be
> completely wrong when set on the fastd server (handling multiple clients).
> See my other mail for details.
>
The explanation what not very clear.

A major difference with my tests is that batman 2016.4 choose, according
to the output from batctl, the gateway with the TQ 240 instead of the GW
with TQ 255.

Translated Interface/Location from batctl gwl
   ftun-q0/Q1       (255) mesh-vpn/Q1
*  ftun-q1/Q0       (240) mesh-vpn/Q1

The normal router choose the GW with the higher TQ, which what the
GW attached to the fastd tunnel.

Translated Interface/Location
   ftun-q1/Q0        (238) mesh-vpn/Q1
=> ftun-q0/Q1        (255) mesh-vpn/Q1

As stated on a previous mail all system what all node had a direct
connection to the same GW.


regards,

Jean-Jacques


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Montag, 7. November 2016 07:45:49 CET Jean-Jacques Sarton wrote:
[...]
> A major difference with my tests is that batman 2016.4 choose, according
> to the output from batctl, the gateway with the TQ 240 instead of the GW
> with TQ 255.
> 
> Translated Interface/Location from batctl gwl
>    ftun-q0/Q1       (255) mesh-vpn/Q1
> *  ftun-q1/Q0       (240) mesh-vpn/Q1
> 
> The normal router choose the GW with the higher TQ, which what the
> GW attached to the fastd tunnel.
> 
> Translated Interface/Location
>    ftun-q1/Q0        (238) mesh-vpn/Q1
> => ftun-q0/Q1        (255) mesh-vpn/Q1
> 
> As stated on a previous mail all system what all node had a direct
> connection to the same GW.

This seems to be a completely different topic now.

Just as hint: read the manpage for `batctl`. Especially the section for
gw_mode.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Jean-Jacques Sarton]

[-- Attachment #1.1: Type: text/plain, Size: 1327 bytes --]

Am 07.11.2016 um 09:02 schrieb Sven Eckelmann:
> On Montag, 7. November 2016 07:45:49 CET Jean-Jacques Sarton wrote:
> [...]
>> A major difference with my tests is that batman 2016.4 choose, according
>> to the output from batctl, the gateway with the TQ 240 instead of the GW
>> with TQ 255.
>>
>> Translated Interface/Location from batctl gwl
>>    ftun-q0/Q1       (255) mesh-vpn/Q1
>> *  ftun-q1/Q0       (240) mesh-vpn/Q1
>>
>> The normal router choose the GW with the higher TQ, which what the
>> GW attached to the fastd tunnel.
>>
>> Translated Interface/Location
>>    ftun-q1/Q0        (238) mesh-vpn/Q1
>> => ftun-q0/Q1        (255) mesh-vpn/Q1
>>
>> As stated on a previous mail all system what all node had a direct
>> connection to the same GW.
> 
> This seems to be a completely different topic now.
> 
> Just as hint: read the manpage for `batctl`. Especially the section for
> gw_mode.

I allready read this, all node has class 20. So I have to expect
that the gw Q1 shall be choosed by all involved systems.
The behavior is nit deterministic. A new test today show that
the selected gw is the correct one (with the greater QT)

For me this what a possibly explanation of rebroadcasting.
In the mean time I had understood that this is required.

regards,

Jean-Jacques



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [B.A.T.M.A.N.] Batman an more than one Gateway

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Freitag, 4. November 2016 22:37:24 CET Jean-Jacques Sarton wrote:
> Hello,
> 
> I have take a look to the configuration of our gateways.
> Inho there are some points which are not OK,
> Broadcasts are rebroadecasted on a wired connection,
> this seem for me to be an issue.

No, this is even required on some "wired" connections. For example Matthias 
Schiffer was against a change to remove rebroadcasts from the incoming 
interface when it is not a wifi interface. He requires it because his fastd is 
using non-wifi (so it basically a wired) interfaces. But it doesn't take care 
of any broadcast distributions for data which is incoming. He is relying on 
the fact that broadcast/multicast data he sends from a client to the fastd 
server is automatically rebroadcasted back once to the incoming interface. 
This will then force fastd to send this data to all its clients.

You also don't know what is actually behind the wireless device. So you can 
easily build a setup (yes, I have already seen this) which has a non-
transitive ethernet to ethernet-like bridge device which attaches via a second 
ethernet to the unit running batman-adv. Not rebroadcasting here would again 
create missing broadcast problems like with the standard wifi hidden node 
setups.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]