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
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 uplinkbandwidth ... [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
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 uplinkbandwidth ... [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
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
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.
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.
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
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
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Jean-Jacques Sarton -
Linus Lüssing -
Marek Lindner -
Simon Wunderlich -
Sven Eckelmann