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.