Re: [B.A.T.M.A.N.] No rebroadcast on mesh links

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]