Hi Marek,
if you are advocating in favor of this patch I see no real need to wait for
Linus. Maybe you can help us understand what this patch does and why it is
useful. These were the questions raised in
https://patchwork.open-mesh.org/patch/4384/ and remain unanswered till today.
I am also unclear why this old patch is re-hashed once more since we merged a
patch 3 years ago achieving the same goal without a manual knob. Can somebody
shed some light on this ?
The patch in question:
commit cc1fde312b6d3c010784a80aff9e942e3b16d015
Author: Matthias Schiffer <[email protected]>
Date: Sat Mar 9 23:14:23 2013 +0100
Subject: batman-adv: send each broadcast only once on non-wireless interfaces
this patch/commit addresses another issue than the "new" request 4384:
it limits the number of broadcasts to be transmitted on an interface,
with the limit automatically adjusting depending of type of interface.
Request 4384 allows to suppress broadcast packets completely on the
interface, where the node has received them (no rebroadcast). This is
typical behavior of physical switches, where broadcasts are sent out to
all ports except the one, where the packet was received.
In Freifunk-Environments we have various types of links, and you cannot
determine automatically the interfaces, where you need rebroadcast and
where rebroadcasts should be suppressed. Some examples:
When having Nodes meshing on WLAN (one WLAN Interface per Node) you need
rebroadcasts. If using fastd-VPN connections or tinc without forwarding
enabled and without full meshing you also need rebroadcast.
But when connecting nodes with LAN-Cable and physical switch, or using
tinc with forwarding enabled, or having point-to-point connections,
especially WiFi longshots or PowerLAN-Adapters or other low bandwidth
connections, the rebroadcasts will waste bandwith and/or air time.
Therefore we would prefer to have this setting as a manual setting,
default to rebroadcast being enabled.
This patch is present in Gluon for quite some time now and considered
stable. In practice we can save significant bandwith and ressources on
the Nodes in local mesh clouds having mesh-on-lan with multiple nodes
(and clients). Because of this experience on non-gateway nodes we also
want to use this feature on gateways without gluon, if multiple gateways
are meshed.
If you need more information, please let me know.
Best regards,
Roland.
