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

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

[Roland Volkmann]

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.

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Roland Volkmann]

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
>
> * https://patchwork.open-mesh.org/patch/3434/
> * https://patchwork.open-mesh.org/patch/4384/

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.

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

[Marek Lindner]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Roland Volkmann]

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.

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

[Marek Lindner]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Linus Lüssing]

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 :).

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

[Roland Volkmann]

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.

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

[Linus Lüssing]

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)

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

[Adrian Reyer]

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
-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Adrian Reyer]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

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
-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 461 bytes --]

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

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/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Roland Volkmann]

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.

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

[Marek Lindner]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

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-patches

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Roland Volkmann]

>>> 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.

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 4000 bytes --]

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:
> 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 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Adrian Reyer]

[-- Attachment #1: Type: text/plain, Size: 4368 bytes --]

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
-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 465 bytes --]

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Adrian Reyer]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

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
-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas@lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 465 bytes --]

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

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,

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Linus Lüssing]

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 ;).

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

[Linus Lüssing]

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)

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

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

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 ?

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Linus Lüssing]

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.

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

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

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,


-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Linus Lüssing]

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 :).

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Linus Lüssing]

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.

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

[Roland Volkmann]

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.

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]