Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII
I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help
the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client
All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758)
with this setup, dhcp requests from the mesh sometimes get "lost", either they don't reach f8d11504758 or the reply doesn't get out
this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine.
So, a few questions arise: is it a problem to activate bridge_loop_avoidance=1 in all nodes, regardless of the fact that they "need" it or not? (that is, it is activated on nodes that don't have any ethernet cables connected and couldn't possibly create a bridge loop)
would it make a difference, if I add br-lan to bat0 (batctl if add br-lan) the way I used to do with batman 2012.1 ?
any other thoughts or ideas?
thanks as always!
Gui
Hello Guido,
On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote:
Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII
I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help
There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup.
the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client
All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758)
with this setup, dhcp requests from the mesh sometimes get "lost", either they don't reach f8d11504758 or the reply doesn't get out
Questions: * which node runs the DHCP server? colmena-casa, f8d11504758 or something else? * at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server? * Can you specify "sometimes" a little bit more? What are the circumstances, how often does it happen?
this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine.
Mhm, that's rather strange ... we had a similar problem when ap isolation was activated. Do you have this feature turned on?
So DHCP is only having problems when gw-mode is turned on colmena-casa and f8d11504758?
So, a few questions arise: is it a problem to activate bridge_loop_avoidance=1 in all nodes, regardless of the fact that they "need" it or not? (that is, it is activated on nodes that don't have any ethernet cables connected and couldn't possibly create a bridge loop)
No, that it is not a problem - you can activate it everywhere. It will just send some additional control packets on bat0, but won't do anything as long as it does not detect other gateways.
would it make a difference, if I add br-lan to bat0 (batctl if add br-lan) the way I used to do with batman 2012.1 ?
That won't help, because the design of BLA changed and the old BLA has been removed. Please keep the bridge out of bat0. :)
Cheers, Simon
On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hello Guido,
On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote:
Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII
I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help
There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup.
Yes, I've seen the cl command, but didn't completely understand how to interpret it. For example, right now I see the clients claimed in the cl of mesh nodes, and even the same client claimed in different nodes.
( when I say mesh nodes, and in the rest of the email, i'm referring to http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II#Definition... )
i.e. sample mesh-nodes: root@charly:~# batctl cl Claims announced for the mesh bat0 (orig charly, group id 6412) Client VID Originator [o] (CRC ) * 00:25:d3:f5:93:76 on -1 by charly [x] (77f9) * f8d1113b6e66_eth0 on -1 by charly [x] (77f9)
root@hquilla:~# batctl cl Claims announced for the mesh bat0 (orig hquilla, group id 82cb) Client VID Originator [o] (CRC ) * 00:25:d3:f5:93:76 on -1 by hquilla [x] (c72e) * 00:24:81:4b:ea:6d on -1 by hquilla [x] (c72e)
maybe that's fine because they have different group ids? (??) is there any documentation on the cl output? as far i could interpret, CRC "identifies" a particular version of a table, [o] = [x] means "this is claimed by myself" group id identifies different backbones (like in this case:) http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases#Two...
and VID, is always set to -1 :P oh, maaaaybe it's vlan id (?) since i'm not using VLANs
the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client
All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758)
with this setup, dhcp requests from the mesh sometimes get "lost", either they don't reach f8d11504758 or the reply doesn't get out
Questions:
- which node runs the DHCP server? colmena-casa, f8d11504758 or something else?
Only the node f8d11504758 runs a DHCP server (dnsmasq) on its interface br-lan no other dhcp server is running on the network
- at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server?
Well, I just managed to get a clarifying tcpdump! hquilla sent a select (REQUEST) that reached the wlan0-2 (mesh) interface of f8d11504758 and it was silently dropped (didn't appear on a batctl td of bat0) this repeated several times, until a lucky REQUEST managed to pass through, was sniffed at bat0, and got a reply from dnsmasq
I couldn't see any difference between the unlucky and lucky REQUESTs or DISCOVERs, but running a "batctl cl -w1" did the trick: when the client is currently claimed by f8d11504758 as in * hquilla_eth0 on -1 by f8d11504758 [x] (d38b)
both the REQUESTs and DISCOVERs reach dnsmasq fine
but if the client is currently claimed by colmena-casa as in * hquilla_eth0 on -1 by colmena-casa [ ] (3d7f) these discover/requests get dropped by batman when they arrive through wlan0-2
- Can you specify "sometimes" a little bit more? What are the circumstances, how often does it happen?
Well, most of the time :) dhcp clients keep trying and eventually they get the lease, but in unlucky times that might even take hours :( at any point in time, there are "lucky" clients who can get a lease and renew it without problem, and other "unlucky" that can't get a reply at all.
from what i've just seen at the "batctl cl", this luck is related to being claimed by the "right" backbone node.
this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine.
Mhm, that's rather strange ... we had a similar problem when ap isolation was activated. Do you have this feature turned on?
Nope
So DHCP is only having problems when gw-mode is turned on colmena-casa and f8d11504758?
gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on every node except f8d11504758, which has gw_mode=server
As far as i can recall, disabling gw_mode=client in every mesh node, solved the problem. But now that i found out about this "batctl td" thing, i'm in doubt about the validity of the previous statement :( i should check again and report.
So, a few questions arise: is it a problem to activate bridge_loop_avoidance=1 in all nodes, regardless of the fact that they "need" it or not? (that is, it is activated on nodes that don't have any ethernet cables connected and couldn't possibly create a bridge loop)
No, that it is not a problem - you can activate it everywhere. It will just send some additional control packets on bat0, but won't do anything as long as it does not detect other gateways.
would it make a difference, if I add br-lan to bat0 (batctl if add br-lan) the way I used to do with batman 2012.1 ?
That won't help, because the design of BLA changed and the old BLA has been removed. Please keep the bridge out of bat0. :)
Ok, thanks a lot for the clarifications!
Have a great day,
Gui
On Wed, Jul 4, 2012 at 9:43 AM, Guido Iribarren guidoiribarren@buenosaireslibre.org wrote:
On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hello Guido,
gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on every node except f8d11504758, which has gw_mode=server
As far as i can recall, disabling gw_mode=client in every mesh node, solved the problem. But now that i found out about this "batctl td" thing, i'm in doubt about the validity of the previous statement :( i should check again and report.
I can now confirm this.
if i set gw_mode=off in a particular mesh node, DHCP requests originating from that node work correctly, even when the mesh node client is claimed by the "wrong" backbone node.
in this scenario: * ruth_eth0 on -1 by colmena-casa [ ] (7a27) * hquilla_eth0 on -1 by colmena-casa [ ] (7a27)
root@ruth:~# batctl gw off root@ruth:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending select for 10.254.0.131... Lease of 10.254.0.131 obtained, lease time 600
root@hquilla:~# batctl gw client root@hquilla:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending discover... Sending discover...^C
when hquilla sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena-casa > f8d11504758: UCAST....... and gets dropped (doesn't reach dnsmasq)
when ruth (gw_mode=off) sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena: BCAST, orig ruth, ...... (then rebroadcasted several times) and it reaches dnsmasq properly.
If you prefer the raw "batctl td" for some eye-injuring reason, here you go: http://pastebin.com/HNBg01hR
hope that helps!
Gui
Hey Guido,
thanks again for the good debugging, that really helped to understand the problem :)
I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes.
Cheers Simon
On Wed, Jul 4, 2012 at 11:05 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hey Guido,
thanks again for the good debugging, that really helped to understand the problem :)
Thanks free software! :D
I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes.
Definitely! here's the output, tho:
Applying ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c Hunk #1 succeeded at 1351 with fuzz 1 (offset -17 lines). Hunk #2 FAILED at 1378. Hunk #3 FAILED at 1423. 2 out of 3 hunks FAILED -- saving rejects to file bridge_loop_avoidance.c.rej patching file bridge_loop_avoidance.h Hunk #1 FAILED at 21. Hunk #2 FAILED at 42. 2 out of 2 hunks FAILED -- saving rejects to file bridge_loop_avoidance.h.rej patching file soft-interface.c Hunk #1 FAILED at 274. Hunk #2 FAILED at 323. 2 out of 2 hunks FAILED -- saving rejects to file soft-interface.c.rej Patch failed! Please fix ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch!
i'm trying to apply against openwrt@torvic:~/trunk/feeds/packages/net/batman-adv$ svn info Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32587 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32579 Last Changed Date: 2012-07-02 13:20:20 -0300 (Mon, 02 Jul 2012)
Visually inspecting the rejects, seems my source code still doesn't have the batadv_ prefix in functions names. i.e.:
int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
I've seen many patches flying around dealing with the batadv_ prefix for dave, but didn't pay much attention to them: which of those should i grab?
Or, Simon, could you kindly send another patch that i can apply cleanly to r32587 of svn://svn.openwrt.org/openwrt/packages/net/batman-adv
in any case, i see the changes are simple, so i *could* try a manual apply of the patch....... but last time i tried (with other patch), it got overwritten by openwrt build system.
Thanks a lot for the support!
Gui
Cheers Simon
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk/0TYwACgkQrzg/fFk7axbznwCg5oyyF4UaWJBV8GXztFSGG8sa vnAAoJYcgNuCcdA5fZKrIvaUE888FzSI =zd3Q -----END PGP SIGNATURE-----
Sorry, my fault. Will send a patch based on maint in a minute.
On Wed, Jul 04, 2012 at 03:12:59PM -0300, Guido Iribarren wrote:
On Wed, Jul 4, 2012 at 11:05 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hey Guido,
thanks again for the good debugging, that really helped to understand the problem :)
Thanks free software! :D
I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes.
Definitely! here's the output, tho:
Applying ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c Hunk #1 succeeded at 1351 with fuzz 1 (offset -17 lines). Hunk #2 FAILED at 1378. Hunk #3 FAILED at 1423. 2 out of 3 hunks FAILED -- saving rejects to file bridge_loop_avoidance.c.rej patching file bridge_loop_avoidance.h Hunk #1 FAILED at 21. Hunk #2 FAILED at 42. 2 out of 2 hunks FAILED -- saving rejects to file bridge_loop_avoidance.h.rej patching file soft-interface.c Hunk #1 FAILED at 274. Hunk #2 FAILED at 323. 2 out of 2 hunks FAILED -- saving rejects to file soft-interface.c.rej Patch failed! Please fix ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch!
i'm trying to apply against openwrt@torvic:~/trunk/feeds/packages/net/batman-adv$ svn info Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32587 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32579 Last Changed Date: 2012-07-02 13:20:20 -0300 (Mon, 02 Jul 2012)
Visually inspecting the rejects, seems my source code still doesn't have the batadv_ prefix in functions names. i.e.:
int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
I've seen many patches flying around dealing with the batadv_ prefix for dave, but didn't pay much attention to them: which of those should i grab?
Or, Simon, could you kindly send another patch that i can apply cleanly to r32587 of svn://svn.openwrt.org/openwrt/packages/net/batman-adv
in any case, i see the changes are simple, so i *could* try a manual apply of the patch....... but last time i tried (with other patch), it got overwritten by openwrt build system.
Thanks a lot for the support!
Gui
Cheers Simon
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk/0TYwACgkQrzg/fFk7axbznwCg5oyyF4UaWJBV8GXztFSGG8sa vnAAoJYcgNuCcdA5fZKrIvaUE888FzSI =zd3Q -----END PGP SIGNATURE-----
On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Sorry, my fault. Will send a patch based on maint in a minute.
Applying ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c
Now i'm having fun, heh Thanks!
Gui
Your patch works flawlessly Simon, I sysupgraded f8d11504758 with the patched batman, and DHCP requests are back to normal when using gw_mode=client
I patched colmena-casa first, but it didn't make a difference; which was expected, since colmena-casa is just a backbone gateway, and it doesn't have the actual DHCP server running, as such, it's only job was to forward unicast requests to f8d11504758, which was already doing fine. The problem was that f8d11504758 was dropping the packets, and with your patch it doesn't anymore. Thanks a lot!
On Wed, Jul 4, 2012 at 3:46 PM, Guido Iribarren guidoiribarren@buenosaireslibre.org wrote:
On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Sorry, my fault. Will send a patch based on maint in a minute.
Applying ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c
Now i'm having fun, heh Thanks!
Gui
Hello Guido,
thank you very much for testing, it's nice to hear that it works! :)
Cheers, Simon On Thu, Jul 05, 2012 at 04:51:57PM -0300, Guido Iribarren wrote:
Your patch works flawlessly Simon, I sysupgraded f8d11504758 with the patched batman, and DHCP requests are back to normal when using gw_mode=client
I patched colmena-casa first, but it didn't make a difference; which was expected, since colmena-casa is just a backbone gateway, and it doesn't have the actual DHCP server running, as such, it's only job was to forward unicast requests to f8d11504758, which was already doing fine. The problem was that f8d11504758 was dropping the packets, and with your patch it doesn't anymore. Thanks a lot!
On Wed, Jul 4, 2012 at 3:46 PM, Guido Iribarren guidoiribarren@buenosaireslibre.org wrote:
On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Sorry, my fault. Will send a patch based on maint in a minute.
Applying ./patches/9999-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c
Now i'm having fun, heh Thanks!
Gui
If the gateway functionality is used, some broadcast packets (DHCP requests) may be transmitted as unicast packets. As the bridge loop avoidance code now only considers the payload Ethernet destination, it may drop the DHCP request for clients which are claimed by other backbone gateways, because it falsely infers from the broadcast address that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used for transmission.
Reported-by: Guido Iribarren guidoiribarren@buenosaireslibre.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- PATCHv2 adds a comment why we are doing this, and adds the is_bcast check to the other is_multicast_ether_addr() check in this function.
PATCH-maint is the backport for maint --- bridge_loop_avoidance.c | 15 +++++++++++---- bridge_loop_avoidance.h | 5 +++-- soft-interface.c | 6 +++++- 3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 8bf9751..2b82a0f 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -1351,6 +1351,7 @@ void bla_free(struct bat_priv *bat_priv) * @bat_priv: the bat priv with all the soft interface information * @skb: the frame to be checked * @vid: the VLAN ID of the frame + * @is_bcast: the packet came in a broadcast packet type. * * bla_rx avoidance checks if: * * we have to race for a claim @@ -1361,7 +1362,8 @@ void bla_free(struct bat_priv *bat_priv) * process the skb. * */ -int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) +int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast) { struct ethhdr *ethhdr; struct claim search_claim, *claim = NULL; @@ -1380,7 +1382,7 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
if (unlikely(atomic_read(&bat_priv->bla_num_requests))) /* don't allow broadcasts while requests are in flight */ - if (is_multicast_ether_addr(ethhdr->h_dest)) + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) goto handled;
memcpy(search_claim.addr, ethhdr->h_source, ETH_ALEN); @@ -1406,8 +1408,13 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) }
/* if it is a broadcast ... */ - if (is_multicast_ether_addr(ethhdr->h_dest)) { - /* ... drop it. the responsible gateway is in charge. */ + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) { + /* ... drop it. the responsible gateway is in charge. + * + * We need to check is_bcast because with the gateway + * feature, broadcasts (like DHCP requests) may be sent + * using a unicast packet type. + */ goto handled; } else { /* seems the client considers us as its best gateway. diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h index e39f93a..dc5227b 100644 --- a/bridge_loop_avoidance.h +++ b/bridge_loop_avoidance.h @@ -23,7 +23,8 @@ #define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA -int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid); +int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast); int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid); int bla_is_backbone_gw(struct sk_buff *skb, struct orig_node *orig_node, int hdr_size); @@ -41,7 +42,7 @@ void bla_free(struct bat_priv *bat_priv); #else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, - short vid) + short vid, bool is_bcast) { return 0; } diff --git a/soft-interface.c b/soft-interface.c index 6e2530b..92a4070 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -256,7 +256,11 @@ void interface_rx(struct net_device *soft_iface, struct bat_priv *bat_priv = netdev_priv(soft_iface); struct ethhdr *ethhdr; struct vlan_ethhdr *vhdr; + struct batman_header *batadv_header = (struct batman_header *)skb->data; short vid __maybe_unused = -1; + bool is_bcast; + + is_bcast = !!(batadv_header->packet_type == BAT_BCAST);
/* check if enough space is available for pulling, and pull */ if (!pskb_may_pull(skb, hdr_size)) @@ -302,7 +306,7 @@ void interface_rx(struct net_device *soft_iface, /* Let the bridge loop avoidance check the packet. If will * not handle it, we can safely push it up. */ - if (bla_rx(bat_priv, skb, vid)) + if (bla_rx(bat_priv, skb, vid, is_bcast)) goto out;
netif_rx(skb);
If the gateway functionality is used, some broadcast packets (DHCP requests) may be transmitted as unicast packets. As the bridge loop avoidance code now only considers the payload Ethernet destination, it may drop the DHCP request for clients which are claimed by other backbone gateways, because it falsely infers from the broadcast address that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used for transmission.
Reported-by: Guido Iribarren guidoiribarren@buenosaireslibre.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- PATCHv2 adds a comment why we are doing this, and adds the is_bcast check to the other is_multicast_ether_addr() check in this function.
PATCH-maint is the backport for maint
PATCH-maint-v2 is even checkpatch clean, and remove obsolete !! --- bridge_loop_avoidance.c | 15 +++++++++++---- bridge_loop_avoidance.h | 5 +++-- soft-interface.c | 6 +++++- 3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 8bf9751..c5863f4 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -1351,6 +1351,7 @@ void bla_free(struct bat_priv *bat_priv) * @bat_priv: the bat priv with all the soft interface information * @skb: the frame to be checked * @vid: the VLAN ID of the frame + * @is_bcast: the packet came in a broadcast packet type. * * bla_rx avoidance checks if: * * we have to race for a claim @@ -1361,7 +1362,8 @@ void bla_free(struct bat_priv *bat_priv) * process the skb. * */ -int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) +int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast) { struct ethhdr *ethhdr; struct claim search_claim, *claim = NULL; @@ -1380,7 +1382,7 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
if (unlikely(atomic_read(&bat_priv->bla_num_requests))) /* don't allow broadcasts while requests are in flight */ - if (is_multicast_ether_addr(ethhdr->h_dest)) + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) goto handled;
memcpy(search_claim.addr, ethhdr->h_source, ETH_ALEN); @@ -1406,8 +1408,13 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) }
/* if it is a broadcast ... */ - if (is_multicast_ether_addr(ethhdr->h_dest)) { - /* ... drop it. the responsible gateway is in charge. */ + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) { + /* ... drop it. the responsible gateway is in charge. + * + * We need to check is_bcast because with the gateway + * feature, broadcasts (like DHCP requests) may be sent + * using a unicast packet type. + */ goto handled; } else { /* seems the client considers us as its best gateway. diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h index e39f93a..dc5227b 100644 --- a/bridge_loop_avoidance.h +++ b/bridge_loop_avoidance.h @@ -23,7 +23,8 @@ #define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA -int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid); +int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast); int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid); int bla_is_backbone_gw(struct sk_buff *skb, struct orig_node *orig_node, int hdr_size); @@ -41,7 +42,7 @@ void bla_free(struct bat_priv *bat_priv); #else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, - short vid) + short vid, bool is_bcast) { return 0; } diff --git a/soft-interface.c b/soft-interface.c index 6e2530b..a0ec0e4 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -256,7 +256,11 @@ void interface_rx(struct net_device *soft_iface, struct bat_priv *bat_priv = netdev_priv(soft_iface); struct ethhdr *ethhdr; struct vlan_ethhdr *vhdr; + struct batman_header *batadv_header = (struct batman_header *)skb->data; short vid __maybe_unused = -1; + bool is_bcast; + + is_bcast = (batadv_header->packet_type == BAT_BCAST);
/* check if enough space is available for pulling, and pull */ if (!pskb_may_pull(skb, hdr_size)) @@ -302,7 +306,7 @@ void interface_rx(struct net_device *soft_iface, /* Let the bridge loop avoidance check the packet. If will * not handle it, we can safely push it up. */ - if (bla_rx(bat_priv, skb, vid)) + if (bla_rx(bat_priv, skb, vid, is_bcast)) goto out;
netif_rx(skb);
On Wednesday, July 04, 2012 20:38:19 Simon Wunderlich wrote:
If the gateway functionality is used, some broadcast packets (DHCP requests) may be transmitted as unicast packets. As the bridge loop avoidance code now only considers the payload Ethernet destination, it may drop the DHCP request for clients which are claimed by other backbone gateways, because it falsely infers from the broadcast address that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used for transmission.
Reported-by: Guido Iribarren guidoiribarren@buenosaireslibre.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de
Applied in revision e324701.
Thanks, Marek
On Wed, Jul 04, 2012 at 09:43:13AM -0300, Guido Iribarren wrote:
On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderlich@s2003.tu-chemnitz.de wrote:
Hello Guido,
On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote:
Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII
I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help
There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup.
Yes, I've seen the cl command, but didn't completely understand how to interpret it. For example, right now I see the clients claimed in the cl of mesh nodes, and even the same client claimed in different nodes.
( when I say mesh nodes, and in the rest of the email, i'm referring to http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II#Definition... )
i.e. sample mesh-nodes: root@charly:~# batctl cl Claims announced for the mesh bat0 (orig charly, group id 6412) Client VID Originator [o] (CRC )
- 00:25:d3:f5:93:76 on -1 by charly [x] (77f9)
- f8d1113b6e66_eth0 on -1 by charly [x] (77f9)
root@hquilla:~# batctl cl Claims announced for the mesh bat0 (orig hquilla, group id 82cb) Client VID Originator [o] (CRC )
- 00:25:d3:f5:93:76 on -1 by hquilla [x] (c72e)
- 00:24:81:4b:ea:6d on -1 by hquilla [x] (c72e)
maybe that's fine because they have different group ids? (??)
Yup. They are not interconnected via Ethernet, so they are in different backbones and have a different group id.
If there are other gatways on the backbone with claims, you should see them in the claim list as well.
is there any documentation on the cl output?
Yup, you can find it here:
http://www.open-mesh.org/wiki/batman-adv/Understand-your-batman-adv-network
as far i could interpret, CRC "identifies" a particular version of a table,
yup.
[o] = [x] means "this is claimed by myself"
yup.
group id identifies different backbones (like in this case:) http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases#Two...
yup.
and VID, is always set to -1 :P oh, maaaaybe it's vlan id (?) since i'm not using VLANs
it means you have no VLAN here.
the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client
All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758)
with this setup, dhcp requests from the mesh sometimes get "lost", either they don't reach f8d11504758 or the reply doesn't get out
Questions:
- which node runs the DHCP server? colmena-casa, f8d11504758 or something else?
Only the node f8d11504758 runs a DHCP server (dnsmasq) on its interface br-lan no other dhcp server is running on the network
OK.
- at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server?
Well, I just managed to get a clarifying tcpdump! hquilla sent a select (REQUEST) that reached the wlan0-2 (mesh) interface of f8d11504758 and it was silently dropped (didn't appear on a batctl td of bat0) this repeated several times, until a lucky REQUEST managed to pass through, was sniffed at bat0, and got a reply from dnsmasq
I couldn't see any difference between the unlucky and lucky REQUESTs or DISCOVERs, but running a "batctl cl -w1" did the trick: when the client is currently claimed by f8d11504758 as in
hquilla_eth0 on -1 by f8d11504758 [x] (d38b)both the REQUESTs and DISCOVERs reach dnsmasq fine
but if the client is currently claimed by colmena-casa as in
hquilla_eth0 on -1 by colmena-casa [ ] (3d7f)these discover/requests get dropped by batman when they arrive through wlan0-2
Ah, this helps. If the client is claimed by colmena-case, the request should go from hquilla to colmena-casa via mesh, and from colmena-casa to f8d11504758 via LAN.
I guess the problem is the interaction between BLA and the gateway feature. The DHCP request is sent via unicast to f8d11504758, but the destination address is still broadcast. The bla implementation in f8d11504758 will then think that colmena-casa also has received the broadcast (but it didn't), and therefore drop it.
I'll send a patch for that soon ...
So DHCP is only having problems when gw-mode is turned on colmena-casa and f8d11504758?
gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on every node except f8d11504758, which has gw_mode=server
As far as i can recall, disabling gw_mode=client in every mesh node, solved the problem. But now that i found out about this "batctl td" thing, i'm in doubt about the validity of the previous statement :( i should check again and report.
That would at least match to the hypothesis. :)
[removed the rest of the text. will send the patch soon ...]
Cheers, Simon
If the gateway functionality is used, some broadcast packets (DHCP requests) may be transmitted as unicast packets. As the bridge loop avoidance code now only considers the payload Ethernet destination, it may drop the DHCP request for clients which are claimed by other backbone gateways, because it falsely infers from the broadcast address that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used for transmission.
Reported-by: Guido Iribarren guidoiribarren@buenosaireslibre.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- bridge_loop_avoidance.c | 6 ++++-- bridge_loop_avoidance.h | 5 +++-- soft-interface.c | 6 +++++- 3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 6452e2f..8478083 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -1368,6 +1368,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv) /* @bat_priv: the bat priv with all the soft interface information * @skb: the frame to be checked * @vid: the VLAN ID of the frame + * @is_bcast: the packet came in a broadcast packet type * * bla_rx avoidance checks if: * * we have to race for a claim @@ -1377,7 +1378,8 @@ void batadv_bla_free(struct batadv_priv *bat_priv) * returns 1, otherwise it returns 0 and the caller shall further * process the skb. */ -int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid) +int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast) { struct ethhdr *ethhdr; struct batadv_claim search_claim, *claim = NULL; @@ -1422,7 +1424,7 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid) }
/* if it is a broadcast ... */ - if (is_multicast_ether_addr(ethhdr->h_dest)) { + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) { /* ... drop it. the responsible gateway is in charge. */ goto handled; } else { diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h index 35d39e3..789cb73 100644 --- a/bridge_loop_avoidance.h +++ b/bridge_loop_avoidance.h @@ -21,7 +21,8 @@ #define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA -int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid); +int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast); int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid); int batadv_bla_is_backbone_gw(struct sk_buff *skb, struct batadv_orig_node *orig_node, int hdr_size); @@ -42,7 +43,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv); #else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int batadv_bla_rx(struct batadv_priv *bat_priv, - struct sk_buff *skb, short vid) + struct sk_buff *skb, short vid, bool is_bcast) { return 0; } diff --git a/soft-interface.c b/soft-interface.c index 96736ea..be39f89 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -274,9 +274,13 @@ void batadv_interface_rx(struct net_device *soft_iface, struct batadv_priv *bat_priv = netdev_priv(soft_iface); struct ethhdr *ethhdr; struct vlan_ethhdr *vhdr; + struct batadv_header *batadv_header = (struct batadv_header *)skb->data; short vid __maybe_unused = -1; + bool is_bcast; __be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
+ is_bcast = !!(batadv_header->packet_type == BATADV_BCAST); + /* check if enough space is available for pulling, and pull */ if (!pskb_may_pull(skb, hdr_size)) goto dropped; @@ -323,7 +327,7 @@ void batadv_interface_rx(struct net_device *soft_iface, /* Let the bridge loop avoidance check the packet. If will * not handle it, we can safely push it up. */ - if (batadv_bla_rx(bat_priv, skb, vid)) + if (batadv_bla_rx(bat_priv, skb, vid, is_bcast)) goto out;
netif_rx(skb);
If the gateway functionality is used, some broadcast packets (DHCP requests) may be transmitted as unicast packets. As the bridge loop avoidance code now only considers the payload Ethernet destination, it may drop the DHCP request for clients which are claimed by other backbone gateways, because it falsely infers from the broadcast address that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used for transmission.
Reported-by: Guido Iribarren guidoiribarren@buenosaireslibre.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de --- PATCHv2 adds a comment why we are doing this, and adds the is_bcast check to the other is_multicast_ether_addr() check in this function, and remove obsolete !!. --- bridge_loop_avoidance.c | 15 +++++++++++---- bridge_loop_avoidance.h | 5 +++-- soft-interface.c | 6 +++++- 3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c index 6452e2f..1af7af5 100644 --- a/bridge_loop_avoidance.c +++ b/bridge_loop_avoidance.c @@ -1368,6 +1368,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv) /* @bat_priv: the bat priv with all the soft interface information * @skb: the frame to be checked * @vid: the VLAN ID of the frame + * @is_bcast: the packet came in a broadcast packet type. * * bla_rx avoidance checks if: * * we have to race for a claim @@ -1377,7 +1378,8 @@ void batadv_bla_free(struct batadv_priv *bat_priv) * returns 1, otherwise it returns 0 and the caller shall further * process the skb. */ -int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid) +int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast) { struct ethhdr *ethhdr; struct batadv_claim search_claim, *claim = NULL; @@ -1396,7 +1398,7 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid)
if (unlikely(atomic_read(&bat_priv->bla_num_requests))) /* don't allow broadcasts while requests are in flight */ - if (is_multicast_ether_addr(ethhdr->h_dest)) + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) goto handled;
memcpy(search_claim.addr, ethhdr->h_source, ETH_ALEN); @@ -1422,8 +1424,13 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid) }
/* if it is a broadcast ... */ - if (is_multicast_ether_addr(ethhdr->h_dest)) { - /* ... drop it. the responsible gateway is in charge. */ + if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) { + /* ... drop it. the responsible gateway is in charge. + * + * We need to check is_bcast because with the gateway + * feature, broadcasts (like DHCP requests) may be sent + * using a unicast packet type. + */ goto handled; } else { /* seems the client considers us as its best gateway. diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h index 35d39e3..789cb73 100644 --- a/bridge_loop_avoidance.h +++ b/bridge_loop_avoidance.h @@ -21,7 +21,8 @@ #define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA -int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid); +int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid, + bool is_bcast); int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid); int batadv_bla_is_backbone_gw(struct sk_buff *skb, struct batadv_orig_node *orig_node, int hdr_size); @@ -42,7 +43,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv); #else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int batadv_bla_rx(struct batadv_priv *bat_priv, - struct sk_buff *skb, short vid) + struct sk_buff *skb, short vid, bool is_bcast) { return 0; } diff --git a/soft-interface.c b/soft-interface.c index 96736ea..ae7d23e 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -274,9 +274,13 @@ void batadv_interface_rx(struct net_device *soft_iface, struct batadv_priv *bat_priv = netdev_priv(soft_iface); struct ethhdr *ethhdr; struct vlan_ethhdr *vhdr; + struct batadv_header *batadv_header = (struct batadv_header *)skb->data; short vid __maybe_unused = -1; + bool is_bcast; __be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
+ is_bcast = (batadv_header->packet_type == BATADV_BCAST); + /* check if enough space is available for pulling, and pull */ if (!pskb_may_pull(skb, hdr_size)) goto dropped; @@ -323,7 +327,7 @@ void batadv_interface_rx(struct net_device *soft_iface, /* Let the bridge loop avoidance check the packet. If will * not handle it, we can safely push it up. */ - if (batadv_bla_rx(bat_priv, skb, vid)) + if (batadv_bla_rx(bat_priv, skb, vid, is_bcast)) goto out;
netif_rx(skb);
b.a.t.m.a.n@lists.open-mesh.org
-
Guido Iribarren -
Marek Lindner -
Simon Wunderlich