On Wed, Sep 25, 2013 at 11:03:48PM +0800, Marek Lindner wrote: > On Tuesday 24 September 2013 16:57:24 Linus Lüssing wrote: > > On Tue, Sep 24, 2013 at 03:46:50PM +0200, Antonio Quartulli wrote: > > > On Tue, Sep 24, 2013 at 03:40:33PM +0200, Linus Lüssing wrote: > > > > > > > > > > > > Using this option wrongly will break your mesh network, use this option > > > > wisely and at your own risk! > > > > > > > > > > > > Exactly for this reason (As we discussed on IRC) I think this mechanism > > > should be reasoned a bit more. > > > > Hm, my personal reason to want such a feature is included, the VPN > > example. And since I know that using batman-adv over VPNs is not > > uncommon, I'd love to have this feature upstream. > > Admittedly, I haven't followed the entire discussion but what speaks against > setting the rebroadcast count define for non-wireless to 0 ? Matthias (if I > am > not mistaken) provided a patch for the wireless / non-wireless distinction > not > too long ago. > Seems way easier as we are looking for a quick and temporary solution ? >
Just to summarize the IRC discussion for the archive: For our case (and about half a dozen other Freifunk communities) this wouldn't work because we'd want to have it to 0 for some VPN interfaces but not all. (*) The bar for introducing new configuration / tuning options is a high one for batman-adv because ease of use is a high priority for the batman team. Therefore things should be automized as much as possible or configuration options should only be introduced if there is a high demand for it. Also if it is easy to misuse such an option and if misuse causes havoc then such patches are not very welcome, too. Since this option can generally be automized (with some, but doable effort) we decided to apply this patch in our project locally and agreed on not bringing the patch posted here upstream now. Cheers, Linus (*) We have a VPN topology with a few, fully meshed master servers and several more clients which are connected to two random master servers. The VPN software we are using, fastd, does not provide any mesh routing / forwarding capabilities (so it kind of behaves like OpenVPN in bridged mode without the client-to-client option or tinc with Mode=switch,Broadcast=no,Forwarding=off).
