[v2,maint] batman-adv: avoid DAT to mess up LAN state

Message ID 1433172597-21776-1-git-send-email-antonio@meshcoding.com (mailing list archive)
State Accepted, archived
Commit 9bbd794030657fe0d38590cd67d4801b989cebf9
Headers

Commit Message

Antonio Quartulli June 1, 2015, 3:29 p.m. UTC
  When a node running DAT receives an ARP request from the LAN for the
first time, it is likely that this node will request the ARP entry
through the distributed ARP table (DAT) in the mesh.

Once a DAT reply is received the asking node must check if the MAC
address for which the IP address has been asked is local. If it is, the
node must drop the ARP reply bceause the client should have replied on
its own locally.

Forwarding this reply means fooling any L2 bridge (e.g. Ethernet
switches) lying between the batman-adv node and the LAN. This happens
because the L2 bridge will think that the client sending the ARP reply
lies somewhere in the mesh, while this node is sitting in the same LAN.

Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---

Properly base this patch on top of maint.


 distributed-arp-table.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)
  

Comments

Marek Lindner June 9, 2015, 2:49 p.m. UTC | #1
On Monday, June 01, 2015 17:29:57 Antonio Quartulli wrote:
> When a node running DAT receives an ARP request from the LAN for the
> first time, it is likely that this node will request the ARP entry
> through the distributed ARP table (DAT) in the mesh.
> 
> Once a DAT reply is received the asking node must check if the MAC
> address for which the IP address has been asked is local. If it is, the
> node must drop the ARP reply bceause the client should have replied on
> its own locally.
> 
> Forwarding this reply means fooling any L2 bridge (e.g. Ethernet
> switches) lying between the batman-adv node and the LAN. This happens
> because the L2 bridge will think that the client sending the ARP reply
> lies somewhere in the mesh, while this node is sitting in the same LAN.
> 
> Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
> Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
> ---
> 
> Properly base this patch on top of maint.
> 
> 
>  distributed-arp-table.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)

Applied in revision 9bbd794.

Thanks,
Marek
  

Patch

diff --git a/distributed-arp-table.c b/distributed-arp-table.c
index da1742d..0d791dc 100644
--- a/distributed-arp-table.c
+++ b/distributed-arp-table.c
@@ -1107,6 +1107,9 @@  void batadv_dat_snoop_outgoing_arp_reply(struct batadv_priv *bat_priv,
  * @bat_priv: the bat priv with all the soft interface information
  * @skb: packet to check
  * @hdr_size: size of the encapsulation header
+ *
+ * Returns true if the packet was snooped and consumed by DAT. False if the
+ * packet has to be delivered to the interface
  */
 bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv,
 					 struct sk_buff *skb, int hdr_size)
@@ -1114,7 +1117,7 @@  bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv,
 	uint16_t type;
 	__be32 ip_src, ip_dst;
 	uint8_t *hw_src, *hw_dst;
-	bool ret = false;
+	bool dropped = false;
 	unsigned short vid;
 
 	if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1143,12 +1146,17 @@  bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv,
 	/* if this REPLY is directed to a client of mine, let's deliver the
 	 * packet to the interface
 	 */
-	ret = !batadv_is_my_client(bat_priv, hw_dst, vid);
+	dropped = !batadv_is_my_client(bat_priv, hw_dst, vid);
+
+	/* if this REPLY is sent on behalf of a client of mine, let's drop the
+	 * packet because the client will reply by itself
+	 */
+	dropped |= batadv_is_my_client(bat_priv, hw_src, vid);
 out:
-	if (ret)
+	if (dropped)
 		kfree_skb(skb);
-	/* if ret == false -> packet has to be delivered to the interface */
-	return ret;
+	/* if dropped == false -> deliver to the interface */
+	return dropped;
 }
 
 /**