Hi,
when having Nodes with wired Mesh-Links, or on point-to-point connections, rebroadcasts on the same interface are unnecessary, because all Nodes receive the broadcast packets at the same time.
On non-gateway nodes (Freifunk-Routers) running firmware "Gluon", there is a patch from Linus Lüssing adding the feature/option "mesh_no_rebroadcast" to batman-adv, which is enabled by default on mesh_vpn interface. Because of the good experience reducing traffic also on other wired mesh links (Mesh-on-LAN / Mesh-on-WAN), this option will also be enabled there by default with the upcoming Gluon v2016.2.
Gatways are not running Gluon, but typically Debian Linux, and there the option "mesh_no_rebroadcast" does not exist on batban-adv.
Are there some (other) features already implemented in batman-adv to prevent rebroadcast of unnecessary mesh packets?
If not, what is the chance to have the functionality implemented by the mentioned patch as part of the original code base?
Background:
At Freifunk-Stuttgart we have multiple distributed gateways connected by layer2-tinc, which is logically the same situation as using LAN-Cables and physical Switch. Avoiding rebroadcast will reduce traffic between the gateways.
Additional info:
On 12.03.2015 Ticket #207 was opened by Ruben Kelevra relating the same issue, but immediately closed due to formal error.
Best regards, Roland.
On Friday 25 March 2016 22:35:43 Roland Volkmann wrote:
If not, what is the chance to have the functionality implemented by the mentioned patch as part of the original code base?
[...]
On 12.03.2015 Ticket #207 was opened by Ruben Kelevra relating the same issue, but immediately closed due to formal error.
Please check
* https://patchwork.open-mesh.org/patch/3434/ * https://patchwork.open-mesh.org/patch/4384/
Kind regards, Sven
Sven Eckelmann schrieb am 25.03.2016 um 23:46:
On Friday 25 March 2016 22:35:43 Roland Volkmann wrote:
If not, what is the chance to have the functionality implemented by the mentioned patch as part of the original code base?
[...]
On 12.03.2015 Ticket #207 was opened by Ruben Kelevra relating the same issue, but immediately closed due to formal error.
Please check
Thank you for response. When looking at "https://patchwork.open-mesh.org/patch/4384/" it seems, the patch isn't implemented because of no more activity after 2 years of discussion.
AFAIK Linus Lüssing, author of the original patch, is still active in batman-adv project:
Linus, can you please bring this issue to a good end? There will be a lot of Freifunk friends happy with it - including me.
With best regards from Stuttgart, Roland.
Roland,
Thank you for response. When looking at "https://patchwork.open-mesh.org/patch/4384/" it seems, the patch isn't implemented because of no more activity after 2 years of discussion.
AFAIK Linus Lüssing, author of the original patch, is still active in batman-adv project:
Linus, can you please bring this issue to a good end? There will be a lot of Freifunk friends happy with it - including me.
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 mschiffer@universe-factory.net Date: Sat Mar 9 23:14:23 2013 +0100 Subject: batman-adv: send each broadcast only once on non-wireless interfaces
On 12.03.2015 Ticket #207 was opened by Ruben Kelevra relating the same issue, but immediately closed due to formal error.
It might appear as a nuisance to you but it is standard Linux kernel practice to send patch submissions to the mailing list. That is why the ticket was closed.
Cheers, Marek
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 mschiffer@universe-factory.net 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.
On Monday, March 28, 2016 15:43:21 Roland Volkmann wrote:
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 mschiffer@universe-factory.net 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.
Thanks for the clarifications. Given the situation at hand it seem fairly simple to extend the existing logic to prevent re-broadcasting on links without packet loss.
I am fully aware that adding a setting presents itself as the easiest solution but it comes with major drawbacks such as:
* Once exposed interfaces to user space can never be removed. We have to carry this around forever. Thus we need a really good reason to do so. * When we let the user decide to configure $something there is a high chance the setting ends up being misconfigured and causing frustration in the end.
Prevent rebroadcasts when possible to reduce overhead is a good idea. However, I'd like to explore all options to auto-detect whether or not rebroadcasts on the same interface are needed or not. The only case requiring investigation is the 'tinc without forwarding' and 'without meshing' ? 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 ?
Cheers, Marek
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 :).
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.
On Mon, Mar 28, 2016 at 11:19:09PM +0200, Roland Volkmann wrote:
But I'm not sure it is possible to detect automatically whether rebroadcast are necessary or not in all cases.
Of course not. But I think Marek's suggestion is a good compromise between the completely manual approach on the one hand and detecting everything automagically in batman-adv on the other.
At least this approach would cover everything we care about for current Freifunk setups for now and many more. Without the user being able to misconfigure something that easily. (usually a user would not set a TRANSITIVE flag on the interface, but e.g. drivers and applications creating the interface would)
Hi,
On Tue, Mar 29, 2016 at 01:52:47AM +0200, Linus Lüssing wrote:
At least this approach would cover everything we care about for current Freifunk setups for now and many more. Without the user being able to misconfigure something that easily. (usually a user would not set a TRANSITIVE flag on the interface, but e.g. drivers and applications creating the interface would)
The interface doesn't have the information needed, so the (assumed) huge effort of bringing in a new flag for all types of network interfaces is somewhat useless. In my eyes we have two types to consider here: 1. lossy links, this is what can be 'fixed' be repeatedly sending a broadcast out 2. different listeners, e.g. due to wifi range. If we have the same listeners for everyone on an interface we don't need a re-broadcast at all. There are many different possibilities to generate the different combinations of 1 and 2 with common hardware. - wifi AP-mode: lossy, same listener - wifi adhoc mode: lossy, different listeners - ethernet cable on a switch with the listeners on: non-lossy, same listeners - ethernet cable towards a wifi-bridge in adhoc mode - ethernet cable towards a wifi-bridge in ap mode - various types of vpn with and without meshing - SoC with wifi attached via vlan in adhoc, station or ap mode - network technologies stacked on others, e.g. tagged vlan a into openvSwitch and the lossy wifi link is the untagged vlan a, while tagged vlan b is plugged into a solid vpn. - add bridges to the game, old style or ovs - add other stuff like ppp, slip, atm, ... I advocate an admin-settable flag for batman, defaulting to the current behaviour. Nothing breaks that way, only batman needs to be adjusted and the patch already exists and is tested. Admins can set the flag if they think they have use for it and they do it knowingly. If they do it 'by accident' it is as little batmans fault as if they earased their disk with some dd-command. Default is sane, just more traffic than necessary in some common szenarios. Even if someone decided that flag would not be needed anymore in some near or far future and therefore it is decided to remove it, only those that wanted to use it get an error message, it is still a functional system. However, I seriously doubt there is a good alternative to manually setting that flag within batman in the forseeable future.
Best regards, Adrian
On Tuesday 29 March 2016 10:37:17 Adrian Reyer wrote: [...]
I advocate an admin-settable flag for batman, defaulting to the current behaviour. Nothing breaks that way, only batman needs to be adjusted and the patch already exists and is tested. Admins can set the flag if they think they have use for it and they do it knowingly.
We still need at least one person interested in this patch who rebases the patch and resubmit its with a convincing commit message.
It would also be interesting if it should be a simple flag or some if exporting the num_bcasts via $something would be sufficient. Or if the num_bcasts should be split into num_bcasts_otherif and num_bcasts_sameif and then exported.
Just keep in mind that this "flag" may has to be kept there until the end of time. So if there is a need for a new setting then it should at least be discussed if this is done right and not that someone else needs to add additional things shortly after it reached the Linux kernel.
Kind regards, Sven
On Tue, Mar 29, 2016 at 11:50:47AM +0200, Sven Eckelmann wrote:
We still need at least one person interested in this patch who rebases the patch and resubmit its with a convincing commit message.
Well, I am a system administrator, no kernel developer. I have limited knowledg about C and verious version control systems. If noone else is willing to do it, I can try.
It would also be interesting if it should be a simple flag or some if exporting the num_bcasts via $something would be sufficient. Or if the num_bcasts should be split into num_bcasts_otherif and num_bcasts_sameif and then exported.
It is two different things, the num_bcasts in my understanding is about how many times the originator sends out its packets to assume everyone has received it. The flag we talk about is about if anyone receiving that packet on an interface has to send it out on that very interface at all, e.g. it is about everyone reachable via that interface sees the same neighbours (e.g. switch) or a different group (e.g. wlan adhoc)
Just keep in mind that this "flag" may has to be kept there until the end of time. So if there is a need for a new setting then it should at least be discussed if this is done right and not that someone else needs to add additional things shortly after it reached the Linux kernel.
Well, someone *might* want to be able to adjust the num_bcasts. However, this is a different thing and neither adressed in that patch, nor a problem I think that needs to be addressed as it seems the automatism does a reasonable decent job here.
Regards, Adrian
On Tuesday 29 March 2016 19:59:57 Adrian Reyer wrote: [...]
It would also be interesting if it should be a simple flag or some if exporting the num_bcasts via $something would be sufficient. Or if the num_bcasts should be split into num_bcasts_otherif and num_bcasts_sameif and then exported.
It is two different things, the num_bcasts in my understanding is about how many times the originator sends out its packets to assume everyone has received it. The flag we talk about is about if anyone receiving that packet on an interface has to send it out on that very interface at all, e.g. it is about everyone reachable via that interface sees the same neighbours (e.g. switch) or a different group (e.g. wlan adhoc)
Thats why I said that it would have to be split into *sameif and *otherif.
And btw. it is not about the originator. It is handled in batadv_send_outstanding_bcast_packet at the same place where you want to have the no_rebroadcast check. no_rebroadcast in the patch we are talking [1,2] about is currently just ignoring the num_bcasts of a hard-interface for some situations (when forw_packet->skb->dev == hard_iface->net_dev).
Kind regards, Sven
[1] https://patchwork.open-mesh.org/patch/3434/ [2] https://patchwork.open-mesh.org/patch/4384/
Sven Eckelmann schrieb am 29.03.2016 um 20:55:
On Tuesday 29 March 2016 19:59:57 Adrian Reyer wrote: [...]
It is two different things, the num_bcasts in my understanding is about how many times the originator sends out its packets to assume everyone has received it. The flag we talk about is about if anyone receiving that packet on an interface has to send it out on that very interface at all, e.g. it is about everyone reachable via that interface sees the same neighbours (e.g. switch) or a different group (e.g. wlan adhoc)
Thats why I said that it would have to be split into *sameif and *otherif.
And btw. it is not about the originator. It is handled in batadv_send_outstanding_bcast_packet at the same place where you want to have the no_rebroadcast check. no_rebroadcast in the patch we are talking [1,2] about is currently just ignoring the num_bcasts of a hard-interface for some situations (when forw_packet->skb->dev == hard_iface->net_dev).
Let's have a look to the source code. The interesting part is function "static void batadv_send_outstanding_bcast_packet(struct work_struct *work)" in file "send.c". There you will find
soft_iface = forw_packet->if_incoming->soft_iface; [...] /* rebroadcast packet */ rcu_read_lock(); list_for_each_entry_rcu(hard_iface, &batadv_hardif_list, list) { if (hard_iface->soft_iface != soft_iface) /* !!! */ continue;
if (forw_packet->num_packets >= hard_iface->num_bcasts) continue;
The if-Statement marked with /* !!! */ results in "true", if incoming-interface isn't identical to outgoing-interface. Because the patch is included after this line, it is relevant for resending broadcasts to the incoming interface only.
Here is an updated version of the patch as it is used in current master branch of gluon matching batman-adv 2016.0:
+ net/batman-adv/hard-interface.c | 2 + + net/batman-adv/send.c | 4 ++ + net/batman-adv/sysfs.c | 59 ++++++++++++++++++++++ + net/batman-adv/types.h | 1 + + 4 files changed, 66 insertions(+) + +diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c +index aea4d06..66a703d 100644 +--- a/net/batman-adv/hard-interface.c ++++ b/net/batman-adv/hard-interface.c +@@ -657,6 +657,8 @@ batadv_hardif_add_interface(struct net_device *net_dev) + /* extra reference for return */ + atomic_set(&hard_iface->refcount, 2); + ++ atomic_set(&hard_iface->no_rebroadcast, 0); ++ + batadv_check_known_mac_addr(hard_iface->net_dev); + list_add_tail_rcu(&hard_iface->list, &batadv_hardif_list); + +diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c +index c188f46..145f7cb 100644 +--- a/net/batman-adv/send.c ++++ b/net/batman-adv/send.c +@@ -535,6 +535,10 @@ static void batadv_send_outstanding_bcast_packet(struct work_struct *work) + if (forw_packet->num_packets >= hard_iface->num_bcasts) + continue; + ++ if (atomic_read(&hard_iface->no_rebroadcast) && ++ forw_packet->skb->dev == hard_iface->net_dev) ++ continue; ++ + /* send a copy of the saved skb */ + skb1 = skb_clone(forw_packet->skb, GFP_ATOMIC); + if (skb1) +diff --git a/net/batman-adv/sysfs.c b/net/batman-adv/sysfs.c +index f38d7b7..600633c 100644 +--- a/net/batman-adv/sysfs.c ++++ b/net/batman-adv/sysfs.c +@@ -131,6 +131,17 @@ struct batadv_attribute batadv_attr_vlan_##_name = { \ + .store = _store, \ + } + ++/* Use this, if you have customized show and store functions ++ * for hard interface attrs ++ */ ++#define BATADV_ATTR_HIF(_name, _mode, _show, _store) \ ++struct batadv_attribute batadv_attr_hif_##_name = { \ ++ .attr = {.name = __stringify(_name), \ ++ .mode = _mode }, \ ++ .show = _show, \ ++ .store = _store, \ ++}; ++ + /* Use this, if you have customized show and store functions */ + #define BATADV_ATTR(_name, _mode, _show, _store) \ + struct batadv_attribute batadv_attr_##_name = { \ +@@ -241,6 +252,52 @@ ssize_t batadv_show_vlan_##_name(struct kobject *kobj, \ + static BATADV_ATTR_VLAN(_name, _mode, batadv_show_vlan_##_name, \ + batadv_store_vlan_##_name) + ++#define BATADV_ATTR_HIF_STORE_BOOL(_name, _post_func) \ ++ssize_t batadv_store_hif_##_name(struct kobject *kobj, \ ++ struct attribute *attr, char *buff, \ ++ size_t count) \ ++{ \ ++ struct net_device *net_dev = batadv_kobj_to_netdev(kobj); \ ++ struct batadv_hard_iface *hard_iface; \ ++ size_t res; \ ++ \ ++ hard_iface = batadv_hardif_get_by_netdev(net_dev); \ ++ if (!hard_iface) \ ++ return 0; \ ++ \ ++ res = __batadv_store_bool_attr(buff, count, _post_func, \ ++ attr, &hard_iface->_name, \ ++ hard_iface->soft_iface); \ ++ batadv_hardif_free_ref(hard_iface); \ ++ return res; \ ++} ++ ++#define BATADV_ATTR_HIF_SHOW_BOOL(_name) \ ++ssize_t batadv_show_hif_##_name(struct kobject *kobj, \ ++ struct attribute *attr, char *buff) \ ++{ \ ++ struct net_device *net_dev = batadv_kobj_to_netdev(kobj); \ ++ struct batadv_hard_iface *hard_iface; \ ++ size_t res; \ ++ \ ++ hard_iface = batadv_hardif_get_by_netdev(net_dev); \ ++ if (!hard_iface) \ ++ return 0; \ ++ \ ++ res = sprintf(buff, "%s\n", \ ++ atomic_read(&hard_iface->_name) == 0 ? \ ++ "disabled" : "enabled"); \ ++ batadv_hardif_free_ref(hard_iface); \ ++ return res; \ ++} ++ ++/* Use this, if you are going to turn a [name] in the vlan struct on or off */ ++#define BATADV_ATTR_HIF_BOOL(_name, _mode, _post_func) \ ++ static BATADV_ATTR_HIF_STORE_BOOL(_name, _post_func) \ ++ static BATADV_ATTR_HIF_SHOW_BOOL(_name) \ ++ static BATADV_ATTR_HIF(_name, _mode, batadv_show_hif_##_name, \ ++ batadv_store_hif_##_name) ++ + static int batadv_store_bool_attr(char *buff, size_t count, + struct net_device *net_dev, + const char *attr_name, atomic_t *attr, +@@ -870,10 +927,12 @@ static ssize_t batadv_show_iface_status(struct kobject *kobj, + static BATADV_ATTR(mesh_iface, S_IRUGO | S_IWUSR, batadv_show_mesh_iface, + batadv_store_mesh_iface); + static BATADV_ATTR(iface_status, S_IRUGO, batadv_show_iface_status, NULL); ++BATADV_ATTR_HIF_BOOL(no_rebroadcast, S_IRUGO | S_IWUSR, NULL); + + static struct batadv_attribute *batadv_batman_attrs[] = { + &batadv_attr_mesh_iface, + &batadv_attr_iface_status, ++ &batadv_attr_hif_no_rebroadcast, + NULL, + }; + +diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h +index 5e8c8df..913f104 100644 +--- a/net/batman-adv/types.h ++++ b/net/batman-adv/types.h +@@ -120,6 +120,7 @@ struct batadv_hard_iface { + struct hlist_head neigh_list; + /* neigh_list_lock protects: neigh_list */ + spinlock_t neigh_list_lock; ++ atomic_t no_rebroadcast; + }; + + /** +-- +2.7.0 +
Best regards, Roland.
On Wednesday, March 30, 2016 01:37:27 Roland Volkmann wrote:
Let's have a look to the source code. The interesting part is function "static void batadv_send_outstanding_bcast_packet(struct work_struct *work)" in file "send.c". There you will find
soft_iface = forw_packet->if_incoming->soft_iface;[...] /* rebroadcast packet */ rcu_read_lock(); list_for_each_entry_rcu(hard_iface, &batadv_hardif_list, list) { if (hard_iface->soft_iface != soft_iface) /* !!! */ continue;
if (forw_packet->num_packets >= hard_iface->num_bcasts) continue;The if-Statement marked with /* !!! */ results in "true", if incoming-interface isn't identical to outgoing-interface. Because the patch is included after this line, it is relevant for resending broadcasts to the incoming interface only.
There seems to be a misunderstanding. With soft-interfaces batman-adv refers to the logic interface created for each mesh (often: bat0, bat1, etc). Consequently, the '!!!' marked if statement checks whether or not a given hard-interface (read: wlan0, eth0, etc) belongs to the same soft-interface the to be forwarded packet belongs to.
Hope that helps!
Cheers, Marek
On Wednesday 30 March 2016 01:37:27 Roland Volkmann wrote: [...]
And btw. it is not about the originator. It is handled in batadv_send_outstanding_bcast_packet at the same place where you want to have the no_rebroadcast check. no_rebroadcast in the patch we are talking [1,2] about is currently just ignoring the num_bcasts of a hard-interface for some situations (when forw_packet->skb->dev == hard_iface->net_dev).
Let's have a look to the source code. The interesting part is function "static void batadv_send_outstanding_bcast_packet(struct work_struct *work)" in file "send.c". There you will find
To what are you answering? At least not to my statement.
soft_iface = forw_packet->if_incoming->soft_iface;[...] /* rebroadcast packet */ rcu_read_lock(); list_for_each_entry_rcu(hard_iface, &batadv_hardif_list, list) { if (hard_iface->soft_iface != soft_iface) /* !!! */ continue;
if (forw_packet->num_packets >= hard_iface->num_bcasts) continue;The if-Statement marked with /* !!! */ results in "true", if incoming-interface isn't identical to outgoing-interface. Because the patch is included after this line, it is relevant for resending broadcasts to the incoming interface only.
No, it isn't about the incoming or outgoing hard-interfaces. See Marek's reply.
Here is an updated version of the patch as it is used in current master branch of gluon matching batman-adv 2016.0:
Not sure why you sent some(tm) patch of a patch in this way when there is a guideline how to correctly send them [1].
Kind regards, Sven
[1] https://www.open-mesh.org/projects/open-mesh/wiki/Contribute#Submitting-patc...
And btw. it is not about the originator. It is handled in batadv_send_outstanding_bcast_packet at the same place where you want to have the no_rebroadcast check. no_rebroadcast in the patch we are talking [1,2] about is currently just ignoring the num_bcasts of a hard-interface for some situations (when forw_packet->skb->dev == hard_iface->net_dev).
Let's have a look to the source code. The interesting part is function "static void batadv_send_outstanding_bcast_packet(struct work_struct *work)" in file "send.c". There you will find
To what are you answering? At least not to my statement.
[...]
No, it isn't about the incoming or outgoing hard-interfaces. See Marek's reply.
Sorry, that was a misunderstanding. Before Marek's explanation (thank you for that) I was read it as comparing incoming to outgoing interface.
Here is an updated version of the patch as it is used in current master branch of gluon matching batman-adv 2016.0:
Not sure why you sent some(tm) patch of a patch in this way when there is a guideline how to correctly send them [1]
This was not an official launch of a patch but for information only. Neither I myself have a required development environment nor do I like to launch Linus' patch as mine. And because of too few knowledge about Linux and batman-adv internals, my only contribution can be to show the relevance of this issue for Freifunk installations, and looking for somebody who can implement the necessary stuff.
Best regards, Roland.
On Tuesday 29 March 2016 20:55:41 Sven Eckelmann wrote:
On Tuesday 29 March 2016 19:59:57 Adrian Reyer wrote: [...]
It would also be interesting if it should be a simple flag or some if exporting the num_bcasts via $something would be sufficient. Or if the num_bcasts should be split into num_bcasts_otherif and num_bcasts_sameif and then exported.
[...]
Thats why I said that it would have to be split into *sameif and *otherif.
Here is what I meant with splitting:
* https://patchwork.open-mesh.org/patch/15945/ * https://patchwork.open-mesh.org/patch/15946/
Kind regards, Sven
Hi Adrian,
On Tuesday 29 March 2016 10:37:17 Adrian Reyer wrote:
Hi,
On Tue, Mar 29, 2016 at 01:52:47AM +0200, Linus Lüssing wrote:
At least this approach would cover everything we care about for current Freifunk setups for now and many more. Without the user being able to misconfigure something that easily. (usually a user would not set a TRANSITIVE flag on the interface, but e.g. drivers and applications creating the interface would)
The interface doesn't have the information needed, so the (assumed) huge effort of bringing in a new flag for all types of network interfaces is somewhat useless. In my eyes we have two types to consider here:
- lossy links, this is what can be 'fixed' be repeatedly sending a
broadcast out 2. different listeners, e.g. due to wifi range. If we have the same listeners for everyone on an interface we don't need a re-broadcast at all. There are many different possibilities to generate the different combinations of 1 and 2 with common hardware.
- wifi AP-mode: lossy, same listener
- wifi adhoc mode: lossy, different listeners
- ethernet cable on a switch with the listeners on: non-lossy, same listeners
- ethernet cable towards a wifi-bridge in adhoc mode
- ethernet cable towards a wifi-bridge in ap mode
- various types of vpn with and without meshing
- SoC with wifi attached via vlan in adhoc, station or ap mode
- network technologies stacked on others, e.g. tagged vlan a into openvSwitch and the lossy wifi link is the untagged vlan a, while tagged vlan b is plugged into a solid vpn.
- add bridges to the game, old style or ovs
- add other stuff like ppp, slip, atm, ...
I don't think we have to pull out every possible case here. People will always be creative in designing their networks, even if their would be some easier or better approaches[tm]. Not supporting everything is not a flaw in my opinion, at least as long as we support sound alternatives.
For example, I don't see why we would need to support not-forwarding/not-full mesh VPNs. We could just require every mesh participant to run batman-adv, and not supporting setups where, for example, the "master" node doesn't speak batman-adv, since that could be easily enabled. If there are multiple independent VPN links, those could be done in seperate interfaces. Is that assumption correct? (Maybe Freifunk people could tell a little bit more).
So far, I see the following scenarios:
Broadcast needed: * WiFi Ad-Hoc * WiFi AP * Ethernet to WiFi Ad-Hoc bridges (is that even used?)
Broadcast not needed * WiFi Point to Point links * Ethernet * VPNs (at least common setups)
As a very easy rule of thumb, we could say that rebroadcasts on the same interface should always be enabled on WiFi and disabled on everything else. Even if we still agree to introduce a flag to change that, that could still be a sound default. Would you agree?
I advocate an admin-settable flag for batman, defaulting to the current behaviour. Nothing breaks that way, only batman needs to be adjusted and the patch already exists and is tested. Admins can set the flag if they think they have use for it and they do it knowingly. If they do it 'by accident' it is as little batmans fault as if they earased their disk with some dd-command. Default is sane, just more traffic than necessary in some common szenarios.
We try to minimize flags and settings in general as a design goal. Other implementations we looked at have too many "tunable" parameters, people writing in forums/mailing lists how and why these settings should be set without really understanding it ... This is why we try to not expose everything, even if we would leave a little bit of room for improvement.
I'm not against the flags, but its good to have a discussion to find out what is really needed ...
Cheers, Simon
Hi Simon,
On Wed, Mar 30, 2016 at 01:58:31PM +0200, Simon Wunderlich wrote:
I don't think we have to pull out every possible case here. People will always be creative in designing their networks, even if their would be some easier or better approaches[tm]. Not supporting everything is not a flaw in my opinion, at least as long as we support sound alternatives.
Sure.
For example, I don't see why we would need to support not-forwarding/not-full mesh VPNs. We could just require every mesh participant to run batman-adv, and not supporting setups where, for example, the "master" node doesn't speak batman-adv, since that could be easily enabled. If there are multiple independent VPN links, those could be done in seperate interfaces. Is that assumption correct? (Maybe Freifunk people could tell a little bit more).
While I don't expect anyone to support anyone elses strange setups, I see no reason to explicitly destroy other setups. batman-adv has an interface, by default bat0, this is similar to a bridge. Attached to that are the various real interfaces, wlan0, eth0, tap0, whatever. And we talk about the broadcasts on those sub-interfaces, not about bat0. We run batman-adv on every node and requiring batman developers to support setups that refuse to use their code would seem very strange to me. A current setup of a freifunk gateway in my freifunk-community hast 2 interfaces attached to a batman instance, 1 fastd reaching all the nodes, here we absolutely need rebroadcasts and 1 tinc interface connecting alle the gateways, there we have full mesh due to tinc already and don't need rebroadcasts. Both interfaces are just tap-Devices, e.g. tap0 and tap1.
So far, I see the following scenarios: Broadcast needed:
- WiFi Ad-Hoc
- WiFi AP
- Ethernet to WiFi Ad-Hoc bridges (is that even used?)
Broadcast not needed
- WiFi Point to Point links
- Ethernet
- VPNs (at least common setups)
As a very easy rule of thumb, we could say that rebroadcasts on the same interface should always be enabled on WiFi and disabled on everything else. Even if we still agree to introduce a flag to change that, that could still be a sound default. Would you agree?
No, a sound default is the behaviour we have now. In worst case it wastes bandwidth, but works. No matter what exact capabilities an interface has. A changed default would instantly break every freifunk-community using batman as to my knowledge they all use a vpn to connect to GWs that *needs* rebroadcasts
We try to minimize flags and settings in general as a design goal. Other implementations we looked at have too many "tunable" parameters, people writing in forums/mailing lists how and why these settings should be set without really understanding it ... This is why we try to not expose everything, even if we would leave a little bit of room for improvement.
I understand this concern very much and I am aware of many, many samples on where things fail due to people just copy&pasting stuff someone else said in some completly different context. I appreciate the idea of the developers to do as few tunables as possible and while I don't regard myself as single-minded, I can't think of a decent, fail-save method of doing an automated detection of the thing I expect from this flag. Be aware, I talk about a single flag only, I want to get rid of the re-broadcasts on interfaces that don't need it. I don't care if there are 1 or 100 rebroadcasts on interfaces that need it and a performance flaw with the latter as batman handles it has not come to my attention as of now. For the first in contrary, I see the impact all the time.
I'm not against the flags, but its good to have a discussion to find out what is really needed ...
I appreciate this discussion as it shows the various pros and cons and enables me to understand how other peoples setups look like, what they focus on and, no matter what the result is, enables me to improove my setups.
Regards, Adrian
On Wednesday 30 March 2016 15:58:42 Adrian Reyer wrote:
A current setup of a freifunk gateway in my freifunk-community hast 2 interfaces attached to a batman instance, 1 fastd reaching all the nodes, here we absolutely need rebroadcasts and 1 tinc interface connecting alle the gateways, there we have full mesh due to tinc already and don't need rebroadcasts. Both interfaces are just tap-Devices, e.g. tap0 and tap1.
I never used fastd. So maybe you can tell me if I summarize it correctly:
* fastd creates point2point vpn-links and makes all of them accessible via tapX * fastd only sends broadcast to its direct neighbors (vpn-links) * the fastd daemon doesn't set some flag to indicate that it doesn't really support broadcasts * you want batman-adv to behave on this tapX exactly like on adhoc (maybe with less re-broadcasts than on adhoc) to keep everything in the same broadcast domain
And for tinc you most likely have configured mst for broadcasts ("tinc handles the forwarding via spanning tree") and don't need batman-adv anymore for re-broadcasts.
Kind regards, Sven
On Wed, Mar 30, 2016 at 06:08:49PM +0200, Sven Eckelmann wrote:
I never used fastd. So maybe you can tell me if I summarize it correctly:
Well, fastd is only a sample, though a very much used one within freifunk.
- fastd creates point2point vpn-links and makes all of them accessible via tapX
yes
- fastd only sends broadcast to its direct neighbors (vpn-links)
yes, there is a real broadcast mode, but without loop avoidance, this is basically never used.
- the fastd daemon doesn't set some flag to indicate that it doesn't really support broadcasts
yes
- you want batman-adv to behave on this tapX exactly like on adhoc (maybe with less re-broadcasts than on adhoc) to keep everything in the same broadcast domain
yes
And for tinc you most likely have configured mst for broadcasts ("tinc handles the forwarding via spanning tree") and don't need batman-adv anymore for re-broadcasts.
indeed Please be aware fastd is only one sample of a vpn solution, there are many others, and most of them unforseeable to us. The suggested flag would fit all of them while not disturbing the save, but traffic consuming default.
Regards, Adrian
Hi Adrian,
On Wednesday 30 March 2016 15:58:42 Adrian Reyer wrote:
[...]
So far, I see the following scenarios:
Broadcast needed:
- WiFi Ad-Hoc
- WiFi AP
- Ethernet to WiFi Ad-Hoc bridges (is that even used?)
Broadcast not needed
- WiFi Point to Point links
- Ethernet
- VPNs (at least common setups)
As a very easy rule of thumb, we could say that rebroadcasts on the same interface should always be enabled on WiFi and disabled on everything else. Even if we still agree to introduce a flag to change that, that could still be a sound default. Would you agree?
No, a sound default is the behaviour we have now. In worst case it wastes bandwidth, but works. No matter what exact capabilities an interface has. A changed default would instantly break every freifunk-community using batman as to my knowledge they all use a vpn to connect to GWs that *needs* rebroadcasts
That is a good point - having the automatism (if we have any) falsely disabling the rebroadcasts may break setups and would be very hard to analyze for users, but the current behaviour is "just" suboptimal but always works. I agree that we should better to default to that.
I thought a little more on automation, but I'm now at a point to agree that there is no good way to do it - at least I'm out of ideas. If anyone else has some ideas, please speak up NOW. :)
So let us consider the other two options:
1.) sysfs flags (as in Linus original patch, or similar):
+ can be integrated fast + is already deployed and tested - requires manual work by the admin, no automatism - we can't expect that other VPNs/subsystems/etc will create automatisms to specifically support batman-adv - requires us to maintain a flag for a special userbase/use case
2.) TRANSITIVE flag as proposed by Linus
+ outside of batman-adv (no maintenance work) + can be set by the user through sysfs, similar to settings of batman-adv + semi-automation possible: Other software like VPNs, or network drivers could set this flag without specifically need to integrate with batman-adv (not sure if this would ever happen though) - will take some time to be adopted: first it goes into the Linux kernel, OpenWRT will have it when it updates to the new kernel. That could easily be 1-2 years - requires more work with on other components, don't know if the various upstream projects will want that - linux-net adoption unclear (but there are already ~18 flags, why not have one more) - Personally, I don't like the name TRANSITIVE. What we really want to say is whether we expect all other nodes in a broadcast domain to receive broadcasts sent by anyone. Maybe we could use a more clear/easier/common name?
Cheers, Simon
Some additions below:
On Thursday 31 March 2016 14:11:19 Simon Wunderlich wrote:
So let us consider the other two options:
1.) sysfs flags (as in Linus original patch, or similar):
- can be integrated fast
One more comment here, fast means that we can integrate it fast in batman-adv, which will help if you use the external module. It will still take some time to dripple into distribution kernels just as Debian. However, compiling the external batman-adv module is easier than upgrading to have netdev flag ...
- is already deployed and tested
- requires manual work by the admin, no automatism
- we can't expect that other VPNs/subsystems/etc will create automatisms to
specifically support batman-adv
- requires us to maintain a flag for a special userbase/use case
2.) TRANSITIVE flag as proposed by Linus
just noticed, actually it was proposed by Marek in the mail before, but only Linus fancy name (in capital!) caught my attention ... :)
Cheers, Simon
On Thu, Mar 31, 2016 at 02:21:03PM +0200, Simon Wunderlich wrote:
Some additions below:
On Thursday 31 March 2016 14:11:19 Simon Wunderlich wrote:
So let us consider the other two options:
1.) sysfs flags (as in Linus original patch, or similar):
- can be integrated fast
One more comment here, fast means that we can integrate it fast in batman-adv, which will help if you use the external module. It will still take some time to dripple into distribution kernels just as Debian. However, compiling the external batman-adv module is easier than upgrading to have netdev flag ...
Same as you compile an external module, you could also apply a single patch to the openwrt kernel I think. I don't really see why this method would be "faster".
The single patch could also be adopted by OpenWrt without waiting for the new kernel.
Cheers,
On Thu, Mar 31, 2016 at 02:21:03PM +0200, Simon Wunderlich wrote:
2.) TRANSITIVE flag as proposed by Linus
just noticed, actually it was proposed by Marek in the mail before, but only Linus fancy name (in capital!) caught my attention ... :)
Yes, Marek's idea unless I misunderstood him :).
Made it capital because other flags like MULTICAST or BROADCAST are in capital in the "ip link" output as well ;).
On Thu, Mar 31, 2016 at 02:11:19PM +0200, Simon Wunderlich wrote:
2.) TRANSITIVE flag as proposed by Linus
- outside of batman-adv (no maintenance work)
- can be set by the user through sysfs, similar to settings of batman-adv
- semi-automation possible: Other software like VPNs, or network drivers
could set this flag without specifically need to integrate with batman-adv (not sure if this would ever happen though)
- will take some time to be adopted: first it goes into the Linux kernel,
OpenWRT will have it when it updates to the new kernel. That could easily be 1-2 years
- requires more work with on other components, don't know if the various
upstream projects will want that
- linux-net adoption unclear (but there are already ~18 flags, why not have
one more)
- Personally, I don't like the name TRANSITIVE. What we really want to say is
whether we expect all other nodes in a broadcast domain to receive broadcasts sent by anyone. Maybe we could use a more clear/easier/common name?
Also:
+ can be used by other routing protocols, too (for instance BABEL and it's split-horizon switch - works similar to the no-rebroadcast sysfs thingy for batman-adv, but for protocol instead of broadcast/multicsat traffic - can still break some setups if bridges on remote devices are involved (for instance bridge between ethernet and adhoc, like Adrian pointed out)
On Thu, Mar 31, 2016 at 05:35:13PM +0200, Linus Lüssing wrote:
On Thu, Mar 31, 2016 at 02:11:19PM +0200, Simon Wunderlich wrote:
- can still break some setups if bridges on remote devices are involved (for instance bridge between ethernet and adhoc, like Adrian pointed out)
in this case the user can still manually change the flag through sysfs no ?
On Thu, Mar 31, 2016 at 11:49:31PM +0800, Antonio Quartulli wrote:
On Thu, Mar 31, 2016 at 05:35:13PM +0200, Linus Lüssing wrote:
On Thu, Mar 31, 2016 at 02:11:19PM +0200, Simon Wunderlich wrote:
- can still break some setups if bridges on remote devices are involved (for instance bridge between ethernet and adhoc, like Adrian pointed out)
in this case the user can still manually change the flag through sysfs no ?
Hm, depends. The owner of that new device with the bridge cannot necessarilly change the config on the batman-adv node as that can be a totally different device with another owner.
Additionally the broken setups might be difficult to debug or even notice.
On Thu, Mar 31, 2016 at 02:11:19PM +0200, Simon Wunderlich wrote:
I thought a little more on automation, but I'm now at a point to agree that there is no good way to do it - at least I'm out of ideas. If anyone else has some ideas, please speak up NOW. :)
Some time ago we had a proposal (by Linus I believe) which was about detecting transitive interfaces by exchanging neighbour tables between peers. This way a node can understand if every other node behind an interface can talk to each other or not.
Although this approach sounds more complex, it would also help optimizing the wifi case: a node can understand if the hosts in an adhoc cells can all talk to each other and then avoid the retransmission (thus saving previous airtime - as we would save bandwidth in a VPN).
The only problem is that this would work only after extending BATMAN V and would unlikely be implemented in BATMAN IV.
Not sure if Linus (?) or anybody else is willing to work on this....but I guess people would like a solution to be used on BATMAN IV ? Or is this an option ?
Cheers,
On Fri, Apr 01, 2016 at 12:01:41AM +0800, Antonio Quartulli wrote:
On Thu, Mar 31, 2016 at 02:11:19PM +0200, Simon Wunderlich wrote:
I thought a little more on automation, but I'm now at a point to agree that there is no good way to do it - at least I'm out of ideas. If anyone else has some ideas, please speak up NOW. :)
Some time ago we had a proposal (by Linus I believe) which was about detecting transitive interfaces by exchanging neighbour tables between peers. This way a node can understand if every other node behind an interface can talk to each other or not.
Basically the first ELP patches had provided that information already, there was a table of neighbors together with the measured link RX metric. But the ELP version merged now is simpler with less overhead and does not have such a table anymore, as the link metric is now provided by mac80211 / the rate selection algorithm.
Although this approach sounds more complex, it would also help optimizing the wifi case: a node can understand if the hosts in an adhoc cells can all talk to each other and then avoid the retransmission (thus saving previous airtime - as we would save bandwidth in a VPN).
Indeed.
The only problem is that this would work only after extending BATMAN V and would unlikely be implemented in BATMAN IV.
I wouldn't see it as a problem but a feature instead, helping to motivate to migrate to BATMAN V ;). Also, Matthias provides Debian packages for BATMAN IV which includes the manual switch, so it shouldn't be too painful for BATMAN IV users either.
Not sure if Linus (?) or anybody else is willing to work on this....but I guess people would like a solution to be used on BATMAN IV ? Or is this an option ?
Back then I think I said (and this is still the case) I would love to work on a detection mechanism, but only once the multicast things are finished. I don't want to drag multiple patchsets along for years.
If anyone else wants to work on that, great :).
On Thursday 31 March 2016 14:11:19 Simon Wunderlich wrote:
[...]
1.) sysfs flags (as in Linus original patch, or similar):
- can be integrated fast
- is already deployed and tested
- requires manual work by the admin, no automatism
- we can't expect that other VPNs/subsystems/etc will create automatisms to
specifically support batman-adv
- requires us to maintain a flag for a special userbase/use case
2.) TRANSITIVE flag as proposed by Linus
- outside of batman-adv (no maintenance work)
- can be set by the user through sysfs, similar to settings of batman-adv
- semi-automation possible: Other software like VPNs, or network drivers
could set this flag without specifically need to integrate with batman-adv (not sure if this would ever happen though)
- will take some time to be adopted: first it goes into the Linux kernel,
OpenWRT will have it when it updates to the new kernel. That could easily be 1-2 years
- requires more work with on other components, don't know if the various
upstream projects will want that
- linux-net adoption unclear (but there are already ~18 flags, why not have
one more)
- Personally, I don't like the name TRANSITIVE. What we really want to say
is whether we expect all other nodes in a broadcast domain to receive broadcasts sent by anyone. Maybe we could use a more clear/easier/common name?
short heads up here:
We had a longer phone call yesterday with Marek, Antonio, Linus, Sven and myself discussing this issue and how to move forward.
We agreed that the sysfs variant should be our last resort since we don't want to expose too many "tuning" options in batman-adv as we already discussed in this thread.
Instead, we want to try getting the TRANSITIVE flag into the kernel, which would not only leave the tuning outside of batman-adv but also enables other protocols and applications to do the right settings. Linus agreed to prepare a patch for that, and we will help pushing it.
Let's see how that goes. :)
Cheers, Simon
On Wednesday 13 April 2016 14:17:41 Simon Wunderlich wrote: [...]
We had a longer phone call yesterday with Marek, Antonio, Linus, Sven and myself discussing this issue and how to move forward.
This is not correct. I was not in the call for most of the time and left before a decision was made and before any progress towards a decision was made.
Kind regards, Sven
On Mon, Mar 28, 2016 at 11:19:09PM +0200, Roland Volkmann wrote:
Node A cannot know, whether you have scenario 1 or 2.
But an ethernet driver or mac80211 with AP/STA interfaces (without ap-isolation) could. Or tinc with forwarding enabled would know. All these can be pretty sure that things are transitive and could set a TRANSITIVE flag quite safely.
Any other interface type, driver etc. would leave the TRANSITIVE flag unset by default to be on the safe side.
Linus Lüssing schrieb am 29.03.2016 um 02:02:
On Mon, Mar 28, 2016 at 11:19:09PM +0200, Roland Volkmann wrote:
Node A cannot know, whether you have scenario 1 or 2.
But an ethernet driver or mac80211 with AP/STA interfaces (without ap-isolation) could. Or tinc with forwarding enabled would know. All these can be pretty sure that things are transitive and could set a TRANSITIVE flag quite safely.
Any other interface type, driver etc. would leave the TRANSITIVE flag unset by default to be on the safe side.
Thank you for your explanations. Indeed covering most cases automatically but still have a knob for very special environments is a very good idea. I'm looking forward having this available - hopefully in short term.
Best regards, Roland.
Hey Linus,
On Tuesday 29 March 2016 02:02:19 Linus Lüssing wrote:
On Mon, Mar 28, 2016 at 11:19:09PM +0200, Roland Volkmann wrote:
Node A cannot know, whether you have scenario 1 or 2.
But an ethernet driver or mac80211 with AP/STA interfaces (without ap-isolation) could. Or tinc with forwarding enabled would know. All these can be pretty sure that things are transitive and could set a TRANSITIVE flag quite safely.
Any other interface type, driver etc. would leave the TRANSITIVE flag unset by default to be on the safe side.
what do you think the chances are for linux-net guys to adopt this flag? We could send an RFC to see how they would feel about it. I remember last time I wanted to change something in SKB struct, they didn't like that at all (maybe for good reason). Could be that they don't want to "bloat" the flags too, but we can/should try.
The other question would be more practical: This would not be backward compatible with older kernels, so everyone who wants to use that new features would need to upgrade the kernel (or wait until new kernels are available). Do you agree?
Cheers, Simon
b.a.t.m.a.n@lists.open-mesh.org
-
Adrian Reyer -
Antonio Quartulli -
Linus Lüssing -
Marek Lindner -
Roland Volkmann -
Simon Wunderlich -
Sven Eckelmann