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

Roland Volkmann
2016-03-28T21:19:09Z

Linus Lüssing schrieb am 28.03.2016 um 21:11:
> On Mon, Mar 28, 2016 at 10:43:39PM +0800, Marek Lindner wrote:
>> Can you provide insights as to what that means and whether or not
>> tinc/fastd 'export' their internal state via an interface flag or
>> something along those lines ?
> Oh, that's a cool idea! Similar to the flag "MULTICAST" you can
> see via an "ip link", to have a flag like "TRANSITIVE", for instance,
> right? (and a net_device flag, configurable via ioctl if I don't
> mix up the internals)
>
> mac80211 could unset it by default for adhoc interfaces or if
> ap-isolation is enabled. tinc, fastd or OpenVPN could set or unset
> it on their interfaces depending on their specific configuration.
> ethernet drivers would have it enabled by default. For bridges
> some more thought might be needed, what to inherit from the bridge
> slaves on the upper bridge interface.
>
> Safe and transparent for the user. I like that idea :).

Because I'm not a Linux specialist knowing internal details, I like to
see the issue in competent hands. My view is on functional level only,
so if (additional) features are needed to optimize existing
Freifunk-Environments, I try to get help. Whatever implementation will
provide this functionality is ok for me and hopefully the Freifunk
communities.

But I'm not sure it is possible to detect automatically whether
rebroadcast are necessary or not in all cases. Let's assume 3 Nodes A, B, C.
Scenario 1: 2 fastd-Links, A-B and A-C
Scenario 2: 3 fastd-Links, A-B, A-C and B-C (this I called "full mesh")

Node A cannot know, whether you have scenario 1 or 2. But in scenario 1
you need rebroadcast on Node A, while in scenario 2 rebroadcasts can be
avoided. IMHO this must be configured manually.

Best regards,
Roland.