Hi Simon,
On Wed, Mar 30, 2016 at 01:58:31PM +0200, Simon Wunderlich wrote:
I don't think we have to pull out every possible case here. People will always be creative in designing their networks, even if their would be some easier or better approaches[tm]. Not supporting everything is not a flaw in my opinion, at least as long as we support sound alternatives.
Sure.
For example, I don't see why we would need to support not-forwarding/not-full mesh VPNs. We could just require every mesh participant to run batman-adv, and not supporting setups where, for example, the "master" node doesn't speak batman-adv, since that could be easily enabled. If there are multiple independent VPN links, those could be done in seperate interfaces. Is that assumption correct? (Maybe Freifunk people could tell a little bit more).
While I don't expect anyone to support anyone elses strange setups, I see no reason to explicitly destroy other setups. batman-adv has an interface, by default bat0, this is similar to a bridge. Attached to that are the various real interfaces, wlan0, eth0, tap0, whatever. And we talk about the broadcasts on those sub-interfaces, not about bat0. We run batman-adv on every node and requiring batman developers to support setups that refuse to use their code would seem very strange to me. A current setup of a freifunk gateway in my freifunk-community hast 2 interfaces attached to a batman instance, 1 fastd reaching all the nodes, here we absolutely need rebroadcasts and 1 tinc interface connecting alle the gateways, there we have full mesh due to tinc already and don't need rebroadcasts. Both interfaces are just tap-Devices, e.g. tap0 and tap1.
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
We try to minimize flags and settings in general as a design goal. Other implementations we looked at have too many "tunable" parameters, people writing in forums/mailing lists how and why these settings should be set without really understanding it ... This is why we try to not expose everything, even if we would leave a little bit of room for improvement.
I understand this concern very much and I am aware of many, many samples on where things fail due to people just copy&pasting stuff someone else said in some completly different context. I appreciate the idea of the developers to do as few tunables as possible and while I don't regard myself as single-minded, I can't think of a decent, fail-save method of doing an automated detection of the thing I expect from this flag. Be aware, I talk about a single flag only, I want to get rid of the re-broadcasts on interfaces that don't need it. I don't care if there are 1 or 100 rebroadcasts on interfaces that need it and a performance flaw with the latter as batman handles it has not come to my attention as of now. For the first in contrary, I see the impact all the time.
I'm not against the flags, but its good to have a discussion to find out what is really needed ...
I appreciate this discussion as it shows the various pros and cons and enables me to understand how other peoples setups look like, what they focus on and, no matter what the result is, enables me to improove my setups.
Regards, Adrian