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.
