Hi Adrian,
On Tuesday 29 March 2016 10:37:17 Adrian Reyer wrote:
Hi,
On Tue, Mar 29, 2016 at 01:52:47AM +0200, Linus Lüssing wrote:
At least this approach would cover everything we care about for current Freifunk setups for now and many more. Without the user being able to misconfigure something that easily. (usually a user would not set a TRANSITIVE flag on the interface, but e.g. drivers and applications creating the interface would)
The interface doesn't have the information needed, so the (assumed) huge effort of bringing in a new flag for all types of network interfaces is somewhat useless. In my eyes we have two types to consider here:
- lossy links, this is what can be 'fixed' be repeatedly sending a
broadcast out 2. different listeners, e.g. due to wifi range. If we have the same listeners for everyone on an interface we don't need a re-broadcast at all. There are many different possibilities to generate the different combinations of 1 and 2 with common hardware.
- wifi AP-mode: lossy, same listener
- wifi adhoc mode: lossy, different listeners
- ethernet cable on a switch with the listeners on: non-lossy, same listeners
- ethernet cable towards a wifi-bridge in adhoc mode
- ethernet cable towards a wifi-bridge in ap mode
- various types of vpn with and without meshing
- SoC with wifi attached via vlan in adhoc, station or ap mode
- network technologies stacked on others, e.g. tagged vlan a into openvSwitch and the lossy wifi link is the untagged vlan a, while tagged vlan b is plugged into a solid vpn.
- add bridges to the game, old style or ovs
- add other stuff like ppp, slip, atm, ...
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.
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).
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?
I advocate an admin-settable flag for batman, defaulting to the current behaviour. Nothing breaks that way, only batman needs to be adjusted and the patch already exists and is tested. Admins can set the flag if they think they have use for it and they do it knowingly. If they do it 'by accident' it is as little batmans fault as if they earased their disk with some dd-command. Default is sane, just more traffic than necessary in some common szenarios.
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'm not against the flags, but its good to have a discussion to find out what is really needed ...
Cheers, Simon