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