[B.A.T.M.A.N.] [PATCHv3 0/6] batman-adv: Optimizations for setups running dat and bla

List overview All Threads
Download

newer

older

[B.A.T.M.A.N.] [RFC] batman-adv:...

[B.A.T.M.A.N.] Adhoc0 Interface...

Andreas Pape

6 May 2016 6 May '16

8:58 a.m.

This patchset introduces optimizations for batman-adv in setups having several gateways into a common (switched) Ethernet backbone network especially if dat is additionally enabled.

Using the current implementation with bla and dat enabled, several problems can be observed in a real setup: 1. Multiplication of ARP replies from dat enabled gateways and dat enabled mesh nodes leading to an "ARP reply storm" in the common backbone network. 2. In rare corner cases bla does not fully prevent looping of unicast frames in the direction Backbone --> mesh --> backbone and looping of multicast frames in the direction mesh --> backbone --> mesh. The latter can lead to temporary confusion in the switched backbone resulting in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the dat handling, bla packet forwarding and bla claiming/unclaiming of clients.

v3:

- rebased patchset - moved snooping of ip addresses for dat speed up into separate function - removed "patch of a patch" - removed automatic claiming during check of a claim - fixed issues of the patchset not being compiled due to chosen batman options

Kind regards, Andreas

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Roland Bent, Dr. Martin Heubeck ___________________________________________________________________ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ---------------------------------------------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___________________________________________________________________

Show replies by date

Andreas Pape

6 May 6 May

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

If dat is enabled it must be made sure that only the backbone gw which has claimed the remote destination for the ARP request answers the ARP request directly if the MAC address is known due to the local dat table. This prevents multiple ARP replies in a common backbone if more than one gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/bridge_loop_avoidance.c | 49 ++++++++++++++++++++++++++++++++ net/batman-adv/bridge_loop_avoidance.h | 11 +++++++ net/batman-adv/distributed-arp-table.c | 15 ++++++++++ 3 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index 748a9ea..2f46ce9 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -2045,3 +2045,52 @@ out: batadv_hardif_put(primary_if); return 0; } + +#ifdef CONFIG_BATMAN_ADV_DAT +/** + * batadv_bla_handle_local_claim - check if address is claimed + * + * @bat_priv: the bat priv with all the soft interface information + * @addr: mac address of which the claim status is checked + * @vid: the VLAN ID + * + * addr is checked if this address is claimed by the local device itself. + * + * Return: true if bla is disabled or the mac is claimed by the device, + * false if the device addr is already claimed by another gateway + */ +bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, + u8 *addr, unsigned short vid) +{ + struct batadv_bla_claim search_claim; + struct batadv_bla_claim *claim = NULL; + struct batadv_hard_iface *primary_if = NULL; + bool ret = true; + + if (!atomic_read(&bat_priv->bridge_loop_avoidance)) + return ret; + + primary_if = batadv_primary_if_get_selected(bat_priv); + if (!primary_if) + return ret; + + /* First look if the mac address is claimed */ + ether_addr_copy(search_claim.addr, addr); + search_claim.vid = vid; + + claim = batadv_claim_hash_find(bat_priv, &search_claim); + + /* If there is a claim and we are not owner of the claim, + * return false. + */ + if (claim) { + if (!batadv_compare_eth(claim->backbone_gw->orig, + primary_if->net_dev->dev_addr)) + ret = false; + batadv_claim_put(claim); + } + + batadv_hardif_put(primary_if); + return ret; +} +#endif diff --git a/net/batman-adv/bridge_loop_avoidance.h b/net/batman-adv/bridge_loop_avoidance.h index 0f01dae..cc07be9 100644 --- a/net/batman-adv/bridge_loop_avoidance.h +++ b/net/batman-adv/bridge_loop_avoidance.h @@ -47,6 +47,10 @@ void batadv_bla_update_orig_address(struct batadv_priv *bat_priv, void batadv_bla_status_update(struct net_device *net_dev); int batadv_bla_init(struct batadv_priv *bat_priv); void batadv_bla_free(struct batadv_priv *bat_priv); +#ifdef CONFIG_BATMAN_ADV_DAT +bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr, + unsigned short vid); +#endif

#define BATADV_BLA_CRC_INIT 0 #else /* ifdef CONFIG_BATMAN_ADV_BLA */ @@ -112,6 +116,13 @@ static inline void batadv_bla_free(struct batadv_priv *bat_priv) { }

+static inline +bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr, + unsigned short vid) +{ + return true; +} + #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

#endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */ diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index 278800a..c11f035 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -48,6 +48,7 @@ #include "originator.h" #include "send.h" #include "translation-table.h" +#include "bridge_loop_avoidance.h"

static void batadv_dat_purge(struct work_struct *work);

@@ -1003,6 +1004,20 @@ bool batadv_dat_snoop_outgoing_arp_request(struct batadv_priv *bat_priv, goto out; }

+ /* If BLA is enabled, only send ARP replies if we have claimed + * the destination for the ARP request or if no one else of + * the backbone gws belonging to our backbone has claimed the + * destination. + */ + if (!batadv_bla_handle_local_claim(bat_priv, + dat_entry->mac_addr, vid)) { + batadv_dbg(BATADV_DBG_DAT, bat_priv, + "Device %pM claimed by another backbone gw. Don't send ARP reply!", + dat_entry->mac_addr); + ret = true; + goto out; + } + skb_new = arp_create(ARPOP_REPLY, ETH_P_ARP, ip_src, bat_priv->soft_iface, ip_dst, hw_src, dat_entry->mac_addr, hw_src); -- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Andreas Pape

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

Speeding up dat address lookup is achieved by snooping all incoming ip traffic. This especially increases the propability in bla setups that a gateway into a common backbone network already has a fitting dat entry to answer incoming ARP requests directly coming from the backbone network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/distributed-arp-table.c | 50 ++++++++++++++++++++++++++++++++ net/batman-adv/distributed-arp-table.h | 9 +++++- net/batman-adv/soft-interface.c | 4 ++ 3 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index c11f035..58cb488 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -27,6 +27,7 @@ #include <linux/if_arp.h> #include <linux/if_ether.h> #include <linux/if_vlan.h> +#include <linux/ip.h> #include <linux/in.h> #include <linux/jiffies.h> #include <linux/kernel.h> @@ -362,6 +363,55 @@ out: batadv_dat_entry_put(dat_entry); }

+/** + * batadv_dat_entry_check - check and update a dat entry + * @bat_priv: the bat priv with all the soft interface information + * @skb: socket buffer + * @vid: VLAN identifier + * + * snoops incoming socket buffer for dat cache updates, if dat is enabled. + * Can be called from other modules. + */ +void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb, + unsigned short vid) +{ + struct vlan_ethhdr *vhdr = NULL, tmp_vhdr; + struct ethhdr *ethhdr = NULL; + struct iphdr *iphdr = NULL, tmp_iphdr; + + if (!atomic_read(&bat_priv->distributed_arp_table)) + return; + + ethhdr = eth_hdr(skb); + + switch (ntohs(ethhdr->h_proto)) { + case ETH_P_IP: + iphdr = skb_header_pointer(skb, ETH_HLEN, sizeof(tmp_iphdr), + &tmp_iphdr); + break; + case ETH_P_8021Q: + vhdr = skb_header_pointer(skb, 0, sizeof(tmp_vhdr), + &tmp_vhdr); + if (!vhdr) + break; + if (ntohs(vhdr->h_vlan_encapsulated_proto) == ETH_P_IP) { + iphdr = skb_header_pointer(skb, sizeof(tmp_vhdr), + sizeof(tmp_iphdr), + &tmp_iphdr); + } + break; + } + + if (iphdr) { + batadv_dbg(BATADV_DBG_DAT, bat_priv, + "Snooped IP address: %pI4 %pM (vid: %d)\n", + &iphdr->saddr, ethhdr->h_source, + BATADV_PRINT_VID(vid)); + batadv_dat_entry_add(bat_priv, iphdr->saddr, + ethhdr->h_source, vid); + } +} + #ifdef CONFIG_BATMAN_ADV_DEBUG

/** diff --git a/net/batman-adv/distributed-arp-table.h b/net/batman-adv/distributed-arp-table.h index 813ecea..cf1b93c 100644 --- a/net/batman-adv/distributed-arp-table.h +++ b/net/batman-adv/distributed-arp-table.h @@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv, int batadv_dat_init(struct batadv_priv *bat_priv); void batadv_dat_free(struct batadv_priv *bat_priv); int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset); - +void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb, + unsigned short vid); /** * batadv_dat_inc_counter - increment the correct DAT packet counter * @bat_priv: the bat priv with all the soft interface information @@ -173,6 +174,12 @@ static inline void batadv_dat_inc_counter(struct batadv_priv *bat_priv, { }

+static inline +void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb, + unsigned short vid) +{ +} + #endif /* CONFIG_BATMAN_ADV_DAT */

#endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */ diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c index 81665b1..1f1742a 100644 --- a/net/batman-adv/soft-interface.c +++ b/net/batman-adv/soft-interface.c @@ -28,6 +28,7 @@ #include <linux/fs.h> #include <linux/if_ether.h> #include <linux/if_vlan.h> +#include <linux/ip.h> #include <linux/jiffies.h> #include <linux/kernel.h> #include <linux/kref.h> @@ -442,6 +443,9 @@ void batadv_interface_rx(struct net_device *soft_iface, goto dropped; }

+ /* Snoop incoming traffic for dat update */ + batadv_dat_entry_check(bat_priv, skb, vid); + /* skb->dev & skb->pkt_type are set here */ skb->protocol = eth_type_trans(skb, soft_iface);

-- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Sven Eckelmann

9:53 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Friday 06 May 2016 10:58:23 Andreas Pape wrote:

...

diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c index 81665b1..1f1742a 100644 --- a/net/batman-adv/soft-interface.c +++ b/net/batman-adv/soft-interface.c @@ -28,6 +28,7 @@ #include <linux/fs.h> #include <linux/if_ether.h> #include <linux/if_vlan.h> +#include <linux/ip.h> #include <linux/jiffies.h> #include <linux/kernel.h> #include <linux/kref.h>

Haven't really looked at your patchset but was just interested in this new function. But I didn't came to look at it because I saw this weird include. Doesn't seem to make sense here at all when you look at the rest of the changes in this file:

...

@@ -442,6 +443,9 @@ void batadv_interface_rx(struct net_device *soft_iface, goto dropped; }

/* Snoop incoming traffic for dat update */

batadv_dat_entry_check(bat_priv, skb, vid);

/* skb->dev & skb->pkt_type are set here */ skb->protocol = eth_type_trans(skb, soft_iface);

Kind regards, Sven

Sven Eckelmann

10:03 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

Hi,

just some ideas (maybe not all of them are good):

[...]

...

```
  ethhdr = eth_hdr(skb);
```
```
  switch (ntohs(ethhdr->h_proto)) {
```
```
  case ETH_P_IP:
```

          iphdr = skb_header_pointer(skb, ETH_HLEN, sizeof(tmp_iphdr),

                                     &tmp_iphdr);

```
          break;
```
```
  case ETH_P_8021Q:
```

          vhdr = skb_header_pointer(skb, 0, sizeof(tmp_vhdr),

                                    &tmp_vhdr);

```
          if (!vhdr)
```
```
                  break;
```

Do we need to continue here when there is no vhdr? Maybe just return.

...

          if (ntohs(vhdr->h_vlan_encapsulated_proto) == ETH_P_IP) {

Maybe the check here could be inverted to just return when this is not ETH_P_IP

...

                  iphdr = skb_header_pointer(skb, sizeof(tmp_vhdr),

                                             sizeof(tmp_iphdr),

                                             &tmp_iphdr);

```
          }
```
```
          break;
```
```
  }
```
```
  if (iphdr) {
```

You could just modify the check to:

if (!iphdr) return;

Kind regards, Sven

Linus Lüssing

19 May 19 May

7:33 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...

Speeding up dat address lookup is achieved by snooping all incoming ip traffic. This especially increases the propability in bla setups that a gateway into a common backbone network already has a fitting dat entry to answer incoming ARP requests directly coming from the backbone network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape apape@phoenixcontact.com

This patch looks interesting :). Currently we have quite some ARP-requests from gateways to clients left in Freifunk setups (had been asking Antonio about it just yesterday) and looks like this patch could help here.

...

+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
	    unsigned short vid)
+{

[...]

...

batadv_dat_entry_add(bat_priv, iphdr->saddr,

```
		     ethhdr->h_source, vid);
```
}

There is something in batadv_dat_entry_add() that makes me a little worried:

---- if (dat_entry) { if (!batadv_compare_eth(dat_entry->mac_addr, mac_addr)) ether_addr_copy(dat_entry->mac_addr, mac_addr); ----

ether_addr_copy() isn't atomic, there is a race condition between the update and any such check - like the one just above it.

This isn't really a bug of your patchset, but could make this race condition much more likely. In the worst case, a fast IP packet stream would create a constant rewrite and mostly broken dat_entry->mac_addr.

Linus Lüssing

10:22 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Thu, May 19, 2016 at 09:33:12PM +0200, Linus Lüssing wrote:

...

This isn't really a bug of your patchset, but could make this race condition much more likely. In the worst case, a fast IP packet stream would create a constant rewrite and mostly broken dat_entry->mac_addr.

Sorry, this was wrong of me. Assuming no address collision, then this would result to up to one unnecessary ether_addr_copy() on 32bit but no broken dat_entry->mac_addr.

So shouldn't be an issue, sorry.

Linus Lüssing

7:45 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...

+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
	    unsigned short vid)
+{

[...]

...

if (iphdr) {
```
batadv_dbg(BATADV_DBG_DAT, bat_priv,
```

	   "Snooped IP address: %pI4 %pM (vid: %d)\n",

```
	   &iphdr->saddr, ethhdr->h_source,
```
```
	   BATADV_PRINT_VID(vid));
```

batadv_dat_entry_add(bat_priv, iphdr->saddr,

```
		     ethhdr->h_source, vid);
```
}

Not sure whether it is necessary, or whether there is a check somewhere later within DAT. But should we exclude some iphdr->saddr or ethhdr->h_source addresses? For instance a DHCPDISCOVER usually has a zero-ip address.

Linus Lüssing

8:30 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

...

Not sure whether it is necessary, or whether there is a check somewhere later within DAT. But should we exclude some iphdr->saddr or ethhdr->h_source addresses? For instance a DHCPDISCOVER usually has a zero-ip address.

And speaking of DHCP, do you (or anyone else) know, whether a dhcp-server (or its kernel) sends an ARP request before sending a unicast DHCPOFFER? Or do dhcp-servers usually craft DHCPOFFERs in userspace within their daemon including the ethernet header?

If the latter is the case, maybe we could/should dat-snoop the ethernet+IP destination of such DHCPOFFERs in interface_rx(), too?

Linus Lüssing

10:48 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Thu, May 19, 2016 at 10:30:49PM +0200, Linus Lüssing wrote:

...

...
Not sure whether it is necessary, or whether there is a check somewhere later within DAT. But should we exclude some iphdr->saddr or ethhdr->h_source addresses? For instance a DHCPDISCOVER usually has a zero-ip address.

And speaking of DHCP, do you (or anyone else) know, whether a dhcp-server (or its kernel) sends an ARP request before sending a unicast DHCPOFFER? Or do dhcp-servers usually craft DHCPOFFERs in userspace within their daemon including the ethernet header?

If the latter is the case, maybe we could/should dat-snoop the ethernet+IP destination of such DHCPOFFERs in interface_rx(), too?

Did a quick try in VMs with two standard Debian unstable machines using isc-dhcp-client and -server. Also enabled "ping-check false" on the dhcp-server.

Then I do not see any ARP messages, I just see four DHCP packets (see below). And "ip neigh" stays empty.

So it seems that at least the isc-dhcp-server can assemble raw packets, including the ethernet frame (*).

So the DHCPOFFER's ethernet and IP destinations on a batadv_interface_tx() (sorry, wrongly wrote _rx() above) would give us an even earlier opportunity to feed DAT from.

Would that make sense to do so?

(*): Though looking at the code of isc-dhcpd, there seem to be compile-time options for two more, different send_packet() functions which do not always do that.

-----

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 22:32:03.379281 02:04:64:a4:39:e2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:04:64:a4:39:e2 (oui Unknown), length 300, xid 0x17feeb29, Flags [none] Client-Ethernet-Address 02:04:64:a4:39:e2 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Hostname Option 12, length 12: "Linus-Debian" Parameter-Request Option 55, length 13: Subnet-Mask, BR, Time-Zone, Default-Gateway Domain-Name, Domain-Name-Server, Option 119, Hostname Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route NTP 22:32:03.385454 02:04:64:a4:39:c3 (oui Unknown) > 02:04:64:a4:39:e2 (oui Unknown), ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 192.168.123.1.bootps > 192.168.123.50.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x17feeb29, Flags [none] Your-IP 192.168.123.50 Client-Ethernet-Address 02:04:64:a4:39:e2 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.123.1 Lease-Time Option 51, length 4: 600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.123.1 Domain-Name-Server Option 6, length 4: 192.168.123.1 22:32:03.386571 02:04:64:a4:39:e2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:04:64:a4:39:e2 (oui Unknown), length 300, xid 0x17feeb29, Flags [none] Client-Ethernet-Address 02:04:64:a4:39:e2 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Server-ID Option 54, length 4: 192.168.123.1 Requested-IP Option 50, length 4: 192.168.123.50 Hostname Option 12, length 12: "Linus-Debian" Parameter-Request Option 55, length 13: Subnet-Mask, BR, Time-Zone, Default-Gateway Domain-Name, Domain-Name-Server, Option 119, Hostname Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route NTP 22:32:03.398683 02:04:64:a4:39:c3 (oui Unknown) > 02:04:64:a4:39:e2 (oui Unknown), ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 192.168.123.1.bootps > 192.168.123.50.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x17feeb29, Flags [none] Your-IP 192.168.123.50 Client-Ethernet-Address 02:04:64:a4:39:e2 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.123.1 Lease-Time Option 51, length 4: 600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.123.1 Domain-Name-Server Option 6, length 4: 192.168.123.1 -----

Linus Lüssing

11:11 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Thu, May 19, 2016 at 10:30:49PM +0200, Linus Lüssing wrote:

...

Or do dhcp-servers usually craft DHCPOFFERs in userspace within their daemon including the ethernet header?

Just noticed, they have to. The dhcp-server has to fill in the ethernet destination as the kernel cannot provide it via ARP yet - because the dhcp-client has no IP address yet :).

Andreas Pape

20 May 20 May

11:32 a.m.

New subject: [B.A.T.M.A.N.] Antwort: Re: [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

"B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org schrieb am 19.05.2016 21:45:53:

...

Von: Linus Lüssing linus.luessing@c0d3.blue An: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 19.05.2016 21:47 Betreff: Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic Gesendet von: "B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct

sk_buff *skb,

...
        unsigned short vid)
+{
[...]

...
if (iphdr) {
 batadv_dbg(BATADV_DBG_DAT, bat_priv,
       "Snooped IP address: %pI4 %pM (vid: %d)\n",
       &iphdr->saddr, ethhdr->h_source,
       BATADV_PRINT_VID(vid));
 batadv_dat_entry_add(bat_priv, iphdr->saddr,
            ethhdr->h_source, vid);
}
Not sure whether it is necessary, or whether there is a check somewhere later within DAT. But should we exclude some iphdr->saddr or ethhdr->h_source addresses? For instance a DHCPDISCOVER usually has a zero-ip address.

I think you have a good point here. Excluding especially ip addresses like zero-ip address seems reasonable. Although I think that this isn't a problem as long as no one is sending arp requests for such ip addresses, filling the dat table with unreasonable entries isn't a smart idea either. I will add some additional tests here for reasonable ip addresses for the next version of the patchset.

Thanks and regards, Andreas

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Antonio Quartulli

12:56 p.m.

New subject: [B.A.T.M.A.N.] Antwort: Re: [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Fri, May 20, 2016 at 01:32:35PM +0200, Andreas Pape wrote:

...

"B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org schrieb am 19.05.2016 21:45:53:

...
Von: Linus Lüssing linus.luessing@c0d3.blue An: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 19.05.2016 21:47 Betreff: Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic Gesendet von: "B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct

sk_buff *skb,

...
        unsigned short vid)
+{
[...]

...
if (iphdr) {
 batadv_dbg(BATADV_DBG_DAT, bat_priv,
       "Snooped IP address: %pI4 %pM (vid: %d)\n",
       &iphdr->saddr, ethhdr->h_source,
       BATADV_PRINT_VID(vid));
 batadv_dat_entry_add(bat_priv, iphdr->saddr,
            ethhdr->h_source, vid);
}
Not sure whether it is necessary, or whether there is a check somewhere later within DAT. But should we exclude some iphdr->saddr or ethhdr->h_source addresses? For instance a DHCPDISCOVER usually has a zero-ip address.
I think you have a good point here. Excluding especially ip addresses like zero-ip address seems reasonable. Although I think that this isn't a problem as long as no one is sending arp requests for such ip addresses, filling the dat table with unreasonable entries isn't a smart idea either. I will add some additional tests here for reasonable ip addresses for the next version of the patchset.

We already have some checks in the snooping functions that are performed when calling batadv_arp_get_type(). Aren't those enough ?

Cheers,

-- Antonio Quartulli

Antonio Quartulli

1:51 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...

Speeding up dat address lookup is achieved by snooping all incoming ip traffic. This especially increases the propability in bla setups that a gateway into a common backbone network already has a fitting dat entry to answer incoming ARP requests directly coming from the backbone network thus further reducing ARP traffic in the mesh.

Any IP packet can't be sent if an ARP "handshake" has not been performed. This means that when you are snooping an IP packet you have already snooped an ARP packet slightly before. In which case do we really win something ?

On top of that, don't you think that snooping *every* packet will badly affect the performance ? Have you tried measuring the difference ?

Cheers,

-- Antonio Quartulli

Andreas Pape

13 Jun 13 Jun

1:45 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

"B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org schrieb am 20.05.2016 15:51:38:

...

Von: Antonio Quartulli a@unstable.cc An: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 20.05.2016 15:52 Betreff: Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic Gesendet von: "B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org

On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:

...
Speeding up dat address lookup is achieved by snooping all incoming ip traffic. This especially increases the propability in bla setups that a gateway into a common backbone network already has a fitting dat

entry

...

...
to answer incoming ARP requests directly coming from the backbone network thus further reducing ARP traffic in the mesh.

Any IP packet can't be sent if an ARP "handshake" has not been

performed. This

...

means that when you are snooping an IP packet you have already snooped

an ARP

...

packet slightly before. In which case do we really win something ?

In case of a static mesh ("static" in terms of non-moving mesh nodes and when the mesh nodes almost always use the same backbone gateways for a common wired backbone) we gain nothing by snooping every packet. The idea came up when I started experimenting with more dynamic setups where the mesh nodes move around with several gateways into a common wired backbone. In this case routing becomes more dynamically and it is not assured that the traffic from/for a mesh node is always routed via the same gateway which has already snooped the arp traffic.

...

On top of that, don't you think that snooping *every* packet will badly

affect

...

the performance ? Have you tried measuring the difference ?

I'm aware that this has an impact. I can try to measure the difference using my devices but these results of course are related to the hardware I use. I'm lacking experience if such results can be used to generalize a conclusion.

On the other hand this "feature" was not the root cause to post this patchset. More important for me is the prevention of the "arp reply storms" and the temporary loops between backbone network and the mesh because this generates trouble in my application. If it increases the propability for acceptance I don't care to remove the ip source address snooping from the patchset.

Best regards, Andreas

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Linus Lüssing

23 Jun 23 Jun

8:34 p.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

Hi,

On IRC, Matthias just pointed out another, conceptual issue with this patch:

It snoops routed traffic, too. So we would end up with DAT entries for every internet host as well :(.

Regards, Linus

Andreas Pape

6 May 6 May

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 3/6] batman-adv: prevent duplication of ARP replies when DAT is used

If none of the backbone gateways in a bla setup has already knowledge of the mac address searched for in an incoming ARP request from the backbone an address resolution via the DHT of DAT is started. The gateway can send several ARP requests to different DHT nodes and therefore can get several replies. This patch assures that not all of the possible ARP replies are returned to the backbone by checking the local DAT cache of the gateway. If there is an entry in the local cache the gateway has already learned the requested address and there is no need to forward the additional reply to the backbone. Furthermore it is checked if this gateway has claimed the source of the ARP reply and only forwards it to the backbone if it has claimed the source or if there is no claim at all.

Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/distributed-arp-table.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index 58cb488..f025c69 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -1239,6 +1239,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv, __be32 ip_src, ip_dst; u8 *hw_src, *hw_dst; bool dropped = false; + struct batadv_dat_entry *dat_entry = NULL; unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table)) @@ -1258,12 +1259,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv, hw_dst = batadv_arp_hw_dst(skb, hdr_size); ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+ /* If ip_dst is already in cache and has the right mac address, + * drop this frame if this ARP reply is destined for us because it's + * most probably an ARP reply generated by another node of the DHT. + * We have most probably received already a reply earlier. Delivering + * this frame would lead to doubled receive of an ARP reply. + */ + dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid); + if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) { + batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n", + hw_src, &ip_src, hw_dst, &ip_dst, + dat_entry->mac_addr, &dat_entry->ip); + dropped = true; + goto out; + } + /* Update our internal cache with both the IP addresses the node got * within the ARP reply */ batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid); batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+ /* If BLA is enabled, only forward ARP replies if we have claimed the + * source of the ARP reply or if no one else of the same backbone has + * already claimed that client. This prevents that different gateways + * to the same backbone all forward the ARP reply leading to multiple + * replies in the backbone. + */ + if (!batadv_bla_handle_local_claim(bat_priv, hw_src, vid)) { + batadv_dbg(BATADV_DBG_DAT, bat_priv, + "Device %pM claimed by another backbone gw. Drop ARP reply.\n", + hw_src); + dropped = true; + goto out; + } + /* if this REPLY is directed to a client of mine, let's deliver the * packet to the interface */ @@ -1276,6 +1306,8 @@ bool batadv_dat_snoop_incoming_arp_reply(struct batadv_priv *bat_priv, out: if (dropped) kfree_skb(skb); + if (dat_entry) + batadv_dat_entry_put(dat_entry); /* if dropped == false -> deliver to the interface */ return dropped; } -- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Andreas Pape

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 4/6] batman-adv: drop unicast packets from other backbone gw

Additional dropping of unicast packets received from another backbone gw of the same backbone network before being forwarded to the same backbone again is necessary. It was observed in a test setup that in rare cases these frames lead to looping unicast traffic backbone->mesh->backbone.

Acked-by: Simon Wunderlich sw@simonwunderlich.de Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/routing.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c index ae850f2..1ef0735 100644 --- a/net/batman-adv/routing.c +++ b/net/batman-adv/routing.c @@ -864,9 +864,11 @@ int batadv_recv_unicast_packet(struct sk_buff *skb, int check, hdr_size = sizeof(*unicast_packet); enum batadv_subtype subtype; bool is4addr; + struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data; unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data; + ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR; /* the caller function should have already pulled 2 bytes */ @@ -906,6 +908,20 @@ int batadv_recv_unicast_packet(struct sk_buff *skb, } }

+ /* If this is a unicast packet from another backgone gw, + * drop it. + */ + orig_addr = ethhdr->h_source; + orig_node = batadv_orig_hash_find(bat_priv, orig_addr); + if (orig_node && + batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) { + batadv_dbg(BATADV_DBG_BLA, bat_priv, + "Dropped unicast pkt received from another backbone gw %pM.\n", + orig_addr); + batadv_orig_node_put(orig_node); + return NET_RX_DROP; + } + if (batadv_dat_snoop_incoming_arp_request(bat_priv, skb, hdr_size)) goto rx_success; -- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Sven Eckelmann

10:43 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 4/6] batman-adv: drop unicast packets from other backbone gw

On Friday 06 May 2016 10:58:25 Andreas Pape wrote: [...]

...

/* If this is a unicast packet from another backgone gw,

```
 * drop it.
```
```
 */
```
```
orig_addr = ethhdr->h_source;
```

orig_node = batadv_orig_hash_find(bat_priv, orig_addr);

I think we already told this before: This is overwriting the previous orig_node without freeing the reference. It most likely has also other weird consequences. Here is the relevant code to better understand what it overwrites:

if (is4addr) { subtype = unicast_4addr_packet->subtype; batadv_dat_inc_counter(bat_priv, subtype);

/* Only payload data should be considered for speedy * join. For example, DAT also uses unicast 4addr * types, but those packets should not be considered * for speedy join, since the clients do not actually * reside at the sending originator. */ if (subtype == BATADV_P_DATA) { orig_addr = unicast_4addr_packet->src; orig_node = batadv_orig_hash_find(bat_priv, orig_addr); } }

/* If this is a unicast packet from another backgone gw, * drop it. */ orig_addr = ethhdr->h_source; orig_node = batadv_orig_hash_find(bat_priv, orig_addr); if (orig_node && batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) { batadv_dbg(BATADV_DBG_BLA, bat_priv, "recv_unicast_packet(): Dropped unicast pkt received from another backbone gw %pM.\n", orig_addr); batadv_orig_node_put(orig_node); return NET_RX_DROP; }

Kind regards, Sven

Andreas Pape

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 5/6] batman-adv: changed debug messages for easier bla debugging

Some of the bla debug messages are extended and additional messages are added for easier bla debugging. Some debug messages introduced with the dat changes in prior patches of this patch series have been changed to be more compliant to other existing debug messages.

Acked-by: Simon Wunderlich sw@simonwunderlich.de Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/bridge_loop_avoidance.c | 18 ++++++++++++++---- net/batman-adv/routing.c | 2 +- 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index 2f46ce9..c426327 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -715,8 +715,8 @@ static void batadv_bla_add_claim(struct batadv_priv *bat_priv, goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv, - "bla_add_claim(): changing ownership for %pM, vid %d\n", - mac, BATADV_PRINT_VID(vid)); + "bla_add_claim(): changing ownership for %pM, vid %d to gw %pM\n", + mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock); claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN); @@ -1240,10 +1240,13 @@ static void batadv_bla_purge_claims(struct batadv_priv *bat_priv, continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv, - "bla_purge_claims(): %pM, vid %d, time out\n", + "bla_purge_claims(): timed out.\n"); + +purge_now: + batadv_dbg(BATADV_DBG_BLA, bat_priv, + "bla_purge_claims(): %pM, vid %d\n", claim->addr, claim->vid);

-purge_now: batadv_handle_unclaim(bat_priv, primary_if, claim->backbone_gw->orig, claim->addr, claim->vid); @@ -1787,6 +1790,13 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, /* possible optimization: race for a claim */ /* No claim exists yet, claim it for us! */ + + batadv_dbg(BATADV_DBG_BLA, bat_priv, + "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: %s\n", + ethhdr->h_source, + batadv_is_my_client(bat_priv, + ethhdr->h_source, vid) ? + "yes" : "no"); batadv_handle_claim(bat_priv, primary_if, primary_if->net_dev->dev_addr, ethhdr->h_source, vid); diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c index 1ef0735..99186da 100644 --- a/net/batman-adv/routing.c +++ b/net/batman-adv/routing.c @@ -916,7 +916,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb, if (orig_node && batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) { batadv_dbg(BATADV_DBG_BLA, bat_priv, - "Dropped unicast pkt received from another backbone gw %pM.\n", + "recv_unicast_packet(): Dropped unicast pkt received from another backbone gw %pM.\n", orig_addr); batadv_orig_node_put(orig_node); return NET_RX_DROP; -- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

Andreas Pape

8:58 a.m.

New subject: [B.A.T.M.A.N.] [PATCHv3 6/6] batman-adv: handle race condition for claims between gateways

Consider the following situation which has been found in a test setup: Gateway B has claimed client C and gateway A has the same backbone network as B. C sends a broad- or multicast to B and directly after this packet decides to send another packet to A due to a better TQ value. B will forward the broad-/multicast into the backbone as it is the responsible gw and after that A will claim C as it has been chosen by C as the best gateway. If it now happens that A claims C before it has received the broad-/multicast forwarded by B (due to backbone topology or due to some delay in B when forwarding the packet) we get a critical situation: in the current code A will immediately unclaim C when receiving the multicast due to the roaming client scenario although the position of C has not changed in the mesh. If this happens the multi-/broadcast forwarded by B will be sent back into the mesh by A and we have looping packets until one of the gateways claims C again. In order to prevent this, unclaiming of a client due to the roaming client scenario is only done after a certain time is expired after the last claim of the client. 100 ms are used here, which should be slow enough for big backbones and slow gateways but fast enough not to break the roaming client use case.

Acked-by: Simon Wunderlich sw@simonwunderlich.de Signed-off-by: Andreas Pape apape@phoenixcontact.com --- net/batman-adv/bridge_loop_avoidance.c | 20 ++++++++++++++++---- 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index c426327..0790cbc 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -1904,10 +1904,22 @@ bool batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, /* if yes, the client has roamed and we have * to unclaim it. */ - batadv_handle_unclaim(bat_priv, primary_if, - primary_if->net_dev->dev_addr, - ethhdr->h_source, vid); - goto allow; + if (batadv_has_timed_out(claim->lasttime, 100)) { + /* only unclaim if the last claim entry is + * older than 100 ms to make sure we really + * have a roaming client here. + */ + batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming client %pM detected. Unclaim it.\n", + ethhdr->h_source); + batadv_handle_unclaim(bat_priv, primary_if, + primary_if->net_dev->dev_addr, + ethhdr->h_source, vid); + goto allow; + } else { + batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race for claim %pM detected. Drop packet.\n", + ethhdr->h_source); + goto handled; + } }

/* check if it is a multicast/broadcast frame */ -- 1.7.0.4

.................................................................. PHOENIX CONTACT ELECTRONICS GmbH

3075

Age (days ago)

3123

Last active (days ago)

b.a.t.m.a.n@lists.open-mesh.org

20 comments

5 participants

tags (0)

participants (5)

Andreas Pape
Andreas Pape
Antonio Quartulli
Linus Lüssing
Sven Eckelmann