Hi Adrian,
On Wednesday 30 March 2016 15:58:42 Adrian Reyer wrote:
[...]
So far, I see the following scenarios:
Broadcast needed:
- WiFi Ad-Hoc
- WiFi AP
- Ethernet to WiFi Ad-Hoc bridges (is that even used?)
Broadcast not needed
- WiFi Point to Point links
- Ethernet
- VPNs (at least common setups)
As a very easy rule of thumb, we could say that rebroadcasts on the same interface should always be enabled on WiFi and disabled on everything else. Even if we still agree to introduce a flag to change that, that could still be a sound default. Would you agree?
No, a sound default is the behaviour we have now. In worst case it wastes bandwidth, but works. No matter what exact capabilities an interface has. A changed default would instantly break every freifunk-community using batman as to my knowledge they all use a vpn to connect to GWs that *needs* rebroadcasts
That is a good point - having the automatism (if we have any) falsely disabling the rebroadcasts may break setups and would be very hard to analyze for users, but the current behaviour is "just" suboptimal but always works. I agree that we should better to default to that.
I thought a little more on automation, but I'm now at a point to agree that there is no good way to do it - at least I'm out of ideas. If anyone else has some ideas, please speak up NOW. :)
So let us consider the other two options:
1.) sysfs flags (as in Linus original patch, or similar):
+ can be integrated fast + is already deployed and tested - requires manual work by the admin, no automatism - we can't expect that other VPNs/subsystems/etc will create automatisms to specifically support batman-adv - requires us to maintain a flag for a special userbase/use case
2.) TRANSITIVE flag as proposed by Linus
+ outside of batman-adv (no maintenance work) + can be set by the user through sysfs, similar to settings of batman-adv + semi-automation possible: Other software like VPNs, or network drivers could set this flag without specifically need to integrate with batman-adv (not sure if this would ever happen though) - will take some time to be adopted: first it goes into the Linux kernel, OpenWRT will have it when it updates to the new kernel. That could easily be 1-2 years - requires more work with on other components, don't know if the various upstream projects will want that - linux-net adoption unclear (but there are already ~18 flags, why not have one more) - Personally, I don't like the name TRANSITIVE. What we really want to say is whether we expect all other nodes in a broadcast domain to receive broadcasts sent by anyone. Maybe we could use a more clear/easier/common name?
Cheers, Simon