Hi David,
here are two late bugfixes for batman-adv which we would like to have in net if still possible.
Please pull or let me know of any problem!
Thank you, Simon
The following changes since commit fc04fdb2c8a894283259f5621d31d75610701091:
batman-adv: Fix skbuff rcsum on packet reroute (2018-03-18 13:20:32 +0100)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-net-for-davem-20180326
for you to fetch changes up to a752c0a4524889cdc0765925258fd1fd72344100:
batman-adv: fix packet loss for broadcasted DHCP packets to a server (2018-03-24 10:25:49 +0100)
---------------------------------------------------------------- Here are some batman-adv bugfixes:
- fix multicast-via-unicast transmissions for AP isolation and gateway extension, by Linus Luessing (2 patches)
---------------------------------------------------------------- Linus Lüssing (2): batman-adv: fix multicast-via-unicast transmission with AP isolation batman-adv: fix packet loss for broadcasted DHCP packets to a server
net/batman-adv/gateway_client.c | 5 ++++- net/batman-adv/multicast.c | 4 ++-- 2 files changed, 6 insertions(+), 3 deletions(-)
From: Linus Lüssing linus.luessing@c0d3.blue
For multicast frames AP isolation is only supposed to be checked on the receiving nodes and never on the originating one.
Furthermore, the isolation or wifi flag bits should only be intepreted as such for unicast and never multicast TT entries.
By injecting flags to the multicast TT entry claimed by a single target node it was verified in tests that this multicast address becomes unreachable, leading to packet loss.
Omitting the "src" parameter to the batadv_transtable_search() call successfully skipped the AP isolation check and made the target reachable again.
Fixes: 1d8ab8d3c176 ("batman-adv: Modified forwarding behaviour for multicast packets") Signed-off-by: Linus Lüssing linus.luessing@c0d3.blue Signed-off-by: Sven Eckelmann sven@narfation.org Signed-off-by: Simon Wunderlich sw@simonwunderlich.de --- net/batman-adv/multicast.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/multicast.c b/net/batman-adv/multicast.c index d70640135e3a..ee56af5c43e0 100644 --- a/net/batman-adv/multicast.c +++ b/net/batman-adv/multicast.c @@ -814,8 +814,8 @@ static struct batadv_orig_node * batadv_mcast_forw_tt_node_get(struct batadv_priv *bat_priv, struct ethhdr *ethhdr) { - return batadv_transtable_search(bat_priv, ethhdr->h_source, - ethhdr->h_dest, BATADV_NO_FLAGS); + return batadv_transtable_search(bat_priv, NULL, ethhdr->h_dest, + BATADV_NO_FLAGS); }
/**
From: Linus Lüssing linus.luessing@c0d3.blue
DHCP connectivity issues can currently occur if the following conditions are met:
1) A DHCP packet from a client to a server 2) This packet has a multicast destination 3) This destination has a matching entry in the translation table (FF:FF:FF:FF:FF:FF for IPv4, 33:33:00:01:00:02/33:33:00:01:00:03 for IPv6) 4) The orig-node determined by TT for the multicast destination does not match the orig-node determined by best-gateway-selection
In this case the DHCP packet will be dropped.
The "gateway-out-of-range" check is supposed to only be applied to unicasted DHCP packets to a specific DHCP server.
In that case dropping the the unicasted frame forces the client to retry via a broadcasted one, but now directed to the new best gateway.
A DHCP packet with broadcast/multicast destination is already ensured to always be delivered to the best gateway. Dropping a multicasted DHCP packet here will only prevent completing DHCP as there is no other fallback.
So far, it seems the unicast check was implicitly performed by expecting the batadv_transtable_search() to return NULL for multicast destinations. However, a multicast address could have always ended up in the translation table and in fact is now common.
To fix this potential loss of a DHCP client-to-server packet to a multicast address this patch adds an explicit multicast destination check to reliably bail out of the gateway-out-of-range check for such destinations.
The issue and fix were tested in the following three node setup:
- Line topology, A-B-C - A: gateway client, DHCP client - B: gateway server, hop-penalty increased: 30->60, DHCP server - C: gateway server, code modifications to announce FF:FF:FF:FF:FF:FF
Without this patch, A would never transmit its DHCP Discover packet due to an always "out-of-range" condition. With this patch, a full DHCP handshake between A and B was possible again.
Fixes: be7af5cf9cae ("batman-adv: refactoring gateway handling code") Signed-off-by: Linus Lüssing linus.luessing@c0d3.blue Signed-off-by: Sven Eckelmann sven@narfation.org Signed-off-by: Simon Wunderlich sw@simonwunderlich.de --- net/batman-adv/gateway_client.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c index 37fe9a644f22..808d2dd4a839 100644 --- a/net/batman-adv/gateway_client.c +++ b/net/batman-adv/gateway_client.c @@ -746,7 +746,7 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv, { struct batadv_neigh_node *neigh_curr = NULL; struct batadv_neigh_node *neigh_old = NULL; - struct batadv_orig_node *orig_dst_node; + struct batadv_orig_node *orig_dst_node = NULL; struct batadv_gw_node *gw_node = NULL; struct batadv_gw_node *curr_gw = NULL; struct batadv_neigh_ifinfo *curr_ifinfo, *old_ifinfo; @@ -757,6 +757,9 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv,
vid = batadv_get_vid(skb, 0);
+ if (is_multicast_ether_addr(ethhdr->h_dest)) + goto out; + orig_dst_node = batadv_transtable_search(bat_priv, ethhdr->h_source, ethhdr->h_dest, vid); if (!orig_dst_node)
From: Simon Wunderlich sw@simonwunderlich.de Date: Mon, 26 Mar 2018 14:47:52 +0200
here are two late bugfixes for batman-adv which we would like to have in net if still possible.
Please pull or let me know of any problem!
Pulled, thank you Simon.
b.a.t.m.a.n@lists.open-mesh.org
-
David Miller -
Simon Wunderlich