diff mbox

[RFC,2/2] batman-adv: Use broadcast as fallback for gateway replies

Message ID 1465676873-21545-2-git-send-email-sven@narfation.org (mailing list archive)
State RFC, archived
Delegated to: Antonio Quartulli
Headers

Commit Message

Sven Eckelmann June 11, 2016, 8:27 p.m. UTC 
  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(+)

Comments

Linus Lüssing July 1, 2016, 7:30 a.m. UTC | #1 
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?
diff mbox

Patch

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