Speedy join only works when the received packet is either broadcast or an 4addr unicast packet. Thus packets converted from broadcast to unicast via the gateway handling code have to be converted to 4addr packets to allow the receiving gateway server to add the sender address as temporary node to the translation table.
Not doing it will make batman-adv drop the DHCP response in many situations because it doesn't yet have the TT entry for the destination of the DHCP response.
Signed-off-by: Sven Eckelmann sven@narfation.org --- This is completely untested. The RFC was submitted to better explain a problem to Antonio. This problems was noticed in real world setups but these patches were not yet tested in these setups.
net/batman-adv/send.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c index 49836da..0e9445b 100644 --- a/net/batman-adv/send.c +++ b/net/batman-adv/send.c @@ -426,8 +426,8 @@ int batadv_send_skb_via_gw(struct batadv_priv *bat_priv, struct sk_buff *skb, struct batadv_orig_node *orig_node;
orig_node = batadv_gw_get_selected_orig(bat_priv); - return batadv_send_skb_unicast(bat_priv, skb, BATADV_UNICAST, 0, - orig_node, vid); + return batadv_send_skb_unicast(bat_priv, skb, BATADV_UNICAST_4ADDR, + BATADV_P_DATA, orig_node, vid); }
void batadv_forw_packet_free(struct batadv_forw_packet *forw_packet)
The replies from gateway server to gateway client are usually sent via unicast packets. This only works when the destination address for the reply is already known to the translation table. But usually the gateway replies are in response to the first known contact from a device to the gateway server. So it can happen that the TT entry was not yet created.
The gateway server has therefore use broadcast as fallback when the entry is not yet known. This makes the first responses from a DHCP server to a DHCP client more robost.
Signed-off-by: Sven Eckelmann sven@narfation.org --- This is completely untested. The RFC was submitted to better explain a problem to Antonio. This problems was noticed in real world setups but these patches were not yet tested in these setups.
net/batman-adv/soft-interface.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c index 216ac03..5829695 100644 --- a/net/batman-adv/soft-interface.c +++ b/net/batman-adv/soft-interface.c @@ -297,6 +297,18 @@ send: if (forw_mode == BATADV_FORW_SINGLE) do_bcast = false; } + + /* DHCP to from server to client should use unicast when TT + * entry is available and use broadcast as fallback + */ + if (!mcast_single_orig && dhcp_rcp == BATADV_DHCP_TO_CLIENT) { + mcast_single_orig = batadv_transtable_search(bat_priv, + NULL, + dst_hint, + vid); + if (!mcast_single_orig) + do_bcast = true; + } }
batadv_skb_set_priority(skb, 0);
On Sat, Jun 11, 2016 at 10:27:53PM +0200, Sven Eckelmann wrote:
The replies from gateway server to gateway client are usually sent via unicast packets. This only works when the destination address for the reply is already known to the translation table. But usually the gateway replies are in response to the first known contact from a device to the gateway server. So it can happen that the TT entry was not yet created.
The gateway server has therefore use broadcast as fallback when the entry is not yet known. This makes the first responses from a DHCP server to a DHCP client more robost.
Signed-off-by: Sven Eckelmann sven@narfation.org
This is completely untested. The RFC was submitted to better explain a problem to Antonio. This problems was noticed in real world setups but these patches were not yet tested in these setups.
Hm, I'm wondering what kind of overhead implications this could have in larger mesh networks.
Didn't TT support temporary entries? Could the gateway server inject them into its global translation table after parsing an incoming DHCP packet?
b.a.t.m.a.n@lists.open-mesh.org
-
Linus Lüssing -
Sven Eckelmann