B.A.T.M.A.N February 2016

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

21 participants
73 discussions

[B.A.T.M.A.N.] pull request [net-next]: batman-adv 20160223
by Antonio Quartulli 23 Feb '16

23 Feb '16

Hello David, thanks for notifying me about the merge ! This is another pull request intended for net-next and it is basically all cleanup work, mostly by Sven Eckelmann. First the BATADV_BONDING_TQ_THRESHOLD constant gets removed as it was defined but not used anywhere, then all our *_free_ref functions are renamed to *_put in order to follow the kernel naming convention. Please pull or let me know of any problem! Thanks a lot, Antonio The following changes since commit b633353115e352d3c31c12d4c61978c810f05ea1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-02-23 00:09:14 -0500) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem for you to fetch changes up to 7e2366c6267d4ea257c4d0deb2fcf0744749de5f: batman-adv: Rename batadv_tt_orig_list_entry *_free_ref function to *_put (2016-02-23 13:51:01 +0800) ---------------------------------------------------------------- This is a cleanup patchset: first the BATADV_BONDING_TQ_THRESHOLD constant gets removed as it was defined but not used anywhere, then all our *_free_ref functions are renamed to *_put in order to follow the kernel naming convention by Sven Eckelmann. ---------------------------------------------------------------- Antonio Quartulli (1): batman-adv: remove unused BATADV_BONDING_TQ_THRESHOLD constant Sven Eckelmann (19): batman-adv: Rename batadv_orig_node *_free_ref function to *_put batman-adv: Rename batadv_hardif *_free_ref function to *_put batman-adv: Rename batadv_neigh_node *_free_ref function to *_put batman-adv: Rename batadv_neigh_ifinfo *_free_ref function to *_put batman-adv: Rename batadv_orig_ifinfo *_free_ref function to *_put batman-adv: Rename batadv_hardif_neigh *_free_ref function to *_put batman-adv: Rename batadv_backbone_gw *_free_ref function to *_put batman-adv: Rename batadv_claim *_free_ref function to *_put batman-adv: Rename batadv_dat_entry *_free_ref function to *_put batman-adv: Rename batadv_gw_node *_free_ref function to *_put batman-adv: Rename batadv_tvlv_handler *_free_ref function to *_put batman-adv: Rename batadv_tvlv_container *_free_ref function to *_put batman-adv: Rename batadv_softif_vlan *_free_ref function to *_put batman-adv: Rename batadv_nc_node *_free_ref function to *_put batman-adv: Rename batadv_nc_path *_free_ref function to *_put batman-adv: Rename batadv_orig_node_vlan *_free_ref function to *_put batman-adv: Rename batadv_tt_local_entry *_free_ref function to *_put batman-adv: Rename batadv_tt_global_entry *_free_ref function to *_put batman-adv: Rename batadv_tt_orig_list_entry *_free_ref function to *_put net/batman-adv/bat_iv_ogm.c | 72 +++++++++--------- net/batman-adv/bridge_loop_avoidance.c | 63 ++++++++-------- net/batman-adv/distributed-arp-table.c | 24 +++--- net/batman-adv/fragmentation.c | 6 +- net/batman-adv/gateway_client.c | 73 +++++++++--------- net/batman-adv/hard-interface.c | 20 ++--- net/batman-adv/hard-interface.h | 4 +- net/batman-adv/icmp_socket.c | 6 +- net/batman-adv/main.c | 27 ++++--- net/batman-adv/main.h | 5 -- net/batman-adv/network-coding.c | 38 +++++----- net/batman-adv/originator.c | 76 +++++++++---------- net/batman-adv/originator.h | 12 +-- net/batman-adv/routing.c | 48 ++++++------ net/batman-adv/send.c | 12 +-- net/batman-adv/soft-interface.c | 20 ++--- net/batman-adv/soft-interface.h | 2 +- net/batman-adv/sysfs.c | 12 +-- net/batman-adv/translation-table.c | 132 ++++++++++++++++----------------- 19 files changed, 322 insertions(+), 330 deletions(-)

2 21

[B.A.T.M.A.N.] pull request [net]: batman-adv 20160216
by Antonio Quartulli 23 Feb '16

23 Feb '16

Hello David, this pull request is intended for net. Two of the fixes included in this patchset prevent a wrong memory access - it was triggered when removing an object from a list after it was already free'd due to bad reference counting. This misbehaviour existed for both the gw_node and the orig_node_vlan object and has been fixed by Sven Eckelmann. The last patch fixes our interface feasibility check and prevents it from looping indefinitely when two net_device objects reference each other via iflink index (i.e. veth pair), by Andrew Lunn Please pull or let me know of any problem! Thanks a lot, Antonio The following changes since commit db92ea5d4df00271b57d79c2d03dae5a5d60fcc1: dscc4: Undefined signed int shift (2016-02-13 06:10:21 -0500) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem for you to fetch changes up to 1bc4e2b000e7fa9773d6623bc8850561ce10a4fb: batman-adv: Avoid endless loop in bat-on-bat netdevice check (2016-02-16 22:16:33 +0800) ---------------------------------------------------------------- Two of the fixes included in this patchset prevent wrong memory access - it was triggered when removing an object from a list after it was already free'd due to bad reference counting. This misbehaviour existed for both the gw_node and the orig_node_vlan object and has been fixed by Sven Eckelmann. The last patch fixes our interface feasibility check and prevents it from looping indefinitely when two net_device objects reference each other via iflink index (i.e. veth pair), by Andrew Lunn ---------------------------------------------------------------- Andrew Lunn (1): batman-adv: Avoid endless loop in bat-on-bat netdevice check Sven Eckelmann (2): batman-adv: Only put gw_node list reference when removed batman-adv: Only put orig_node_vlan list reference when removed net/batman-adv/gateway_client.c | 7 ++++--- net/batman-adv/hard-interface.c | 25 +++++++++++++++++++++++++ net/batman-adv/translation-table.c | 6 ++++-- 3 files changed, 33 insertions(+), 5 deletions(-)

2 9

[B.A.T.M.A.N.] Still looping packets in bla setup
by Andreas Pape 22 Feb '16

22 Feb '16

Hello Simon, I'm still working with my IT department to be able to send the patches in a way compliant to the documentation provided by Sven. In the meantime I reworked the patches, but I am still struggling with the e-mail client issue. Nevertheless if I apply all the patches I sent earlier (except Patch 4/4 as it was meaningless) I still have 3 problems : 1. I have sometimes looping unicast packets in the direction backbone -> mesh -> backbone. Dropping all unicast traffic received from another backbone gw and destined to be forwarded to the backbone again as you suggested this in an earlier mail solves this issue. Shall I provide an according patch? Shall I add a "Suggested-by" referring to you? I feel a little bit uncomforable with this patch as it seems to be something more like a workaround. The question I cannot answer yet is why the other backbone gws send traffic via the mesh which could be sent via the backbone? 2. Although having the patch for 1. applied, the backbone gateways send claim frames for the devices of their own backbone in rare cases from time to time. I could send a patch for this as it is rather easy to check with the help of the local tt table (batadv_is_my_client) if it is reasonable to send a claim frame for these devices. Again, this patch looks more like a workaround to me as I also cannot explain what really triggers the generation of these claim frames. 3. I see again in rare cases looping multicasts for traffic mesh->backbone->mesh. If I look at the bla debug messages in these cases I see, that a backbone gw holding the claim for the source of the multicast frame thinks that the client belonging to the source address has "roamed" from another mesh node into the backbone network although it didn't. From this I conclude that another backbone gw has forwarded the multicast into the backbone although it shoudn't have done this (having found no claim for the client or erroneously also holding a claim). In this case the backbone gateways seem to be out-of-sync about the actual claim status for that client. This effect only lasts a very short time, as the gateway which found the "roaming" client unclaims it and within a few milliseconds (depending on the traffic generated by the client) another backbone gw (or the same) claims the client again. Of course then the looping of the multicast traffic from the client stops. In my case the sender of the multicast was the bridge interface br0 of a remote mesh node itself. The bat0 softinterface was added to that bridge. The looping multicast then gave me a "bat0: received packet with own address as source address" message. Furthermore that bat0 interface sent a claim frame for the mac of the own bridge (whch is obvious as bat0 received a message from the mesh with a mac address not claimed yet....). This claim frame then produces another "bat0: received packet ..." message. I currently have no workaround for this 3rd issue as all I can image to prevent this will break the "roaming client" scenario for bla. I could even live with this problem as it happens quite seldomly and as it is "self-healing", but it tells my that there might be a sync issue. Do you think that my 1st and 2nd point could also relate to the same problem? In the meantime I looked through the code for hours but I am not able to find something that could explain the observed problem. 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. ___________________________________________________________________

2 2

[B.A.T.M.A.N.] Unsigned integer overflow in batadv_iv_ogm_calc_tq
by Sven Eckelmann 20 Feb '16

20 Feb '16

Hi, just ran my emulation setup [1] and got an integer overflow (undefined behavior): ================================================================================ UBSAN: Undefined behaviour in /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/bat_iv_ogm.c:1246:25 signed integer overflow: 8713350 * 255 cannot be represented in type 'int' CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 4.5.0-rc4-next-20160215 #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 1ffff10001980ea7 10e2f8880f23fbe1 ffff88000cc075b0 ffffffff817f196f 0000000041b58ab3 ffffffff824b0b5f ffffffff817f1894 ffff88000cc075d8 ffff88000cc07588 ffff88000cc075a0 00000000000000ff ffff88000cc07398 Call Trace: <IRQ> [<ffffffff817f196f>] dump_stack+0xdb/0x15c [<ffffffff817f1894>] ? _atomic_dec_and_lock+0xc4/0xc4 [<ffffffff8186c21b>] ubsan_epilogue+0xd/0x8a [<ffffffff8186dbba>] handle_overflow+0x211/0x260 [<ffffffff8186d9a9>] ? __ubsan_handle_negate_overflow+0x1b1/0x1b1 [<ffffffff811ebd6d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffffa0041ed0>] ? batadv_neigh_ifinfo_get+0x330/0x330 [batman_adv] [<ffffffffa0008390>] ? batadv_iv_ogm_process_per_outif+0x1380/0x33f0 [batman_adv] [<ffffffff811ebd6d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8186dc37>] __ubsan_handle_mul_overflow+0xe/0x17 [<ffffffffa0009d74>] batadv_iv_ogm_process_per_outif+0x2d64/0x33f0 [batman_adv] [<ffffffffa0007f27>] ? batadv_iv_ogm_process_per_outif+0xf17/0x33f0 [batman_adv] [<ffffffffa000acd4>] batadv_iv_ogm_receive+0x8d4/0x1d20 [batman_adv] [<ffffffffa000a7c2>] ? batadv_iv_ogm_receive+0x3c2/0x1d20 [batman_adv] [<ffffffffa0037468>] batadv_batman_skb_recv+0x378/0x490 [batman_adv] [<ffffffffa00370f0>] ? batadv_skb_set_priority+0x640/0x640 [batman_adv] [<ffffffff81c68577>] __netif_receive_skb_core+0x7b7/0x2a50 [<ffffffff81c67dc0>] ? __skb_csum_offload_chk+0x12a0/0x12a0 [<ffffffff81c6f215>] __netif_receive_skb+0x55/0x200 [<ffffffff81c6f4b9>] netif_receive_skb_internal+0xf9/0x3e0 [<ffffffff81c6f454>] ? netif_receive_skb_internal+0x94/0x3e0 [<ffffffff81c6f3c0>] ? __netif_receive_skb+0x200/0x200 [<ffffffff81c71bce>] ? dev_gro_receive+0x76e/0x1ca0 [<ffffffff81c71a6c>] ? dev_gro_receive+0x60c/0x1ca0 [<ffffffff81c32331>] ? __netdev_alloc_skb+0x1d1/0x350 [<ffffffff813ec1a6>] ? memcpy+0x36/0x40 [<ffffffff81ce34b0>] ? eth_commit_mac_addr_change+0x70/0x70 [<ffffffff81acc2f4>] ? page_to_skb+0x1d4/0x720 [<ffffffff81c7321a>] napi_gro_receive+0x11a/0x240 [<ffffffff81ad2564>] virtnet_receive+0xc14/0x26b0 [<ffffffff81ad1950>] ? try_fill_recv+0x1530/0x1530 [<ffffffff810cbe70>] ? pvclock_read_flags+0x6d0/0x6d0 [<ffffffff8185bd80>] ? __list_add+0x3f0/0x3f0 [<ffffffff81ad437d>] virtnet_poll+0x1d/0x160 [<ffffffff81c70e63>] net_rx_action+0x6a3/0xca0 [<ffffffff812183ed>] ? handle_irq_event+0xcd/0x1a0 [<ffffffff81223245>] ? handle_fasteoi_irq+0x275/0x8f0 [<ffffffff810fa930>] ? __do_softirq+0x1d0/0x870 [<ffffffff810fa9e8>] __do_softirq+0x288/0x870 [<ffffffff810fb263>] irq_exit+0xe3/0x140 [<ffffffff8102209e>] do_IRQ+0x9e/0x200 [<ffffffff8216fdcc>] common_interrupt+0x8c/0x8c <EOI> [<ffffffff810c9a66>] ? native_safe_halt+0x6/0x10 [<ffffffff811ebd6d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff810364de>] default_idle+0xe/0x20 [<ffffffff8103774a>] arch_cpu_idle+0xa/0x10 [<ffffffff811d199f>] default_idle_call+0x4f/0x80 [<ffffffff811d1c94>] cpu_startup_entry+0x2c4/0x540 [<ffffffff8216eb76>] ? _raw_spin_unlock_irqrestore+0x36/0x60 [<ffffffff811d19d0>] ? default_idle_call+0x80/0x80 [<ffffffff8126f5b8>] ? clockevents_register_device+0xf8/0x1f0 [<ffffffff810a9f9b>] start_secondary+0x35b/0x4c0 [<ffffffff810a9c40>] ? set_cpu_sibling_map+0x2fe0/0x2fe0 ================================================================================ The code is: combined_tq = batadv_ogm_packet->tq * tq_own * tq_asym_penalty * tq_iface_penalty; combined_tq /= BATADV_TQ_MAX_VALUE * BATADV_TQ_MAX_VALUE * BATADV_TQ_MAX_VALUE; It is easy to see that batadv_ogm_packet::tq (u8 255) * tq_own (u8 255) * tq_asym_penalty (int 134) * tq_iface_penalty (int 255) is outside the range of an signed integer (32 bit). The maximum seen here is 255 for each entry. So should tq_iface_penalty + tq_iface_penalty, inv_asym_penalty be changed to unsigned int? --- a/net/batman-adv/bat_iv_ogm.c +++ b/net/batman-adv/bat_iv_ogm.c @@ -1147,9 +1147,10 @@ static int batadv_iv_ogm_calc_tq(struct batadv_orig_node *orig_node, u8 total_count; u8 orig_eq_count, neigh_rq_count, neigh_rq_inv, tq_own; unsigned int neigh_rq_inv_cube, neigh_rq_max_cube; - int tq_asym_penalty, inv_asym_penalty, if_num, ret = 0; + int if_num, ret = 0; + unsigned int tq_asym_penalty, inv_asym_penalty; unsigned int combined_tq; - int tq_iface_penalty; + unsigned int tq_iface_penalty; /* find corresponding one hop neighbor */ rcu_read_lock(); Kind regards, Sven [1] https://www.open-mesh.org/projects/open-mesh/wiki/Emulation_Debug

2 1

[B.A.T.M.A.N.] [PATCH-maint v2] batman-adv: Avoid endless loop in bat-on-bat netdevice check
by Sven Eckelmann 16 Feb '16

16 Feb '16

From: Andrew Lunn <andrew(a)lunn.ch> batman-adv checks in different situation if a new device is already on top of a different batman-adv device. This is done by getting the iflink of a device and all its parent. It assumes that this iflink is always a parent device in an acyclic graph. But this assumption is broken by devices like veth which are actually a pair of two devices linked to each other. The recursive check would therefore get veth0 when calling dev_get_iflink on veth1. And it gets veth0 when calling dev_get_iflink with veth1. Creating a veth pair and loading batman-adv freezes parts of the system ip link add veth0 type veth peer name veth1 modprobe batman-adv An RCU stall will be detected on the system which cannot be fixed. INFO: rcu_sched self-detected stall on CPU 1: (5264 ticks this GP) idle=3e9/140000000000001/0 softirq=144683/144686 fqs=5249 (t=5250 jiffies g=46 c=45 q=43) Task dump for CPU 1: insmod R running task 0 247 245 0x00000008 ffffffff8151f140 ffffffff8107888e ffff88000fd141c0 ffffffff8151f140 0000000000000000 ffffffff81552df0 ffffffff8107b420 0000000000000001 ffff88000e3fa700 ffffffff81540b00 ffffffff8107d667 0000000000000001 Call Trace: <IRQ> [<ffffffff8107888e>] ? rcu_dump_cpu_stacks+0x7e/0xd0 [<ffffffff8107b420>] ? rcu_check_callbacks+0x3f0/0x6b0 [<ffffffff8107d667>] ? hrtimer_run_queues+0x47/0x180 [<ffffffff8107cf9d>] ? update_process_times+0x2d/0x50 [<ffffffff810873fb>] ? tick_handle_periodic+0x1b/0x60 [<ffffffff810290ae>] ? smp_trace_apic_timer_interrupt+0x5e/0x90 [<ffffffff813bbae2>] ? apic_timer_interrupt+0x82/0x90 <EOI> [<ffffffff812c3fd7>] ? __dev_get_by_index+0x37/0x40 [<ffffffffa0031f3e>] ? batadv_hard_if_event+0xee/0x3a0 [batman_adv] [<ffffffff812c5801>] ? register_netdevice_notifier+0x81/0x1a0 [...] This can be avoided by checking if two devices are each others parent and stopping the check in this situation. Fixes: 3d48811b27f5 ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface") Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> [sven(a)narfation.org: rewritten description, extracted fix] Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- v2: - fix kernel-doc warning net/batman-adv/hard-interface.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c index aea4d06..730cfa8 100644 --- a/net/batman-adv/hard-interface.c +++ b/net/batman-adv/hard-interface.c @@ -79,6 +79,28 @@ out: } /** + * batadv_mutual_parents - check if two devices are each others parent + * @dev1: 1st net_device + * @dev2: 2nd net_device + * + * veth devices come in pairs and each is the parent of the other! + * + * Return: true if the devices are each others parent, otherwise false + */ +static bool batadv_mutual_parents(const struct net_device *dev1, + const struct net_device *dev2) +{ + int dev1_parent_iflink = dev_get_iflink(dev1); + int dev2_parent_iflink = dev_get_iflink(dev2); + + if (!dev1_parent_iflink || !dev2_parent_iflink) + return false; + + return (dev1_parent_iflink == dev2->ifindex) && + (dev2_parent_iflink == dev1->ifindex); +} + +/** * batadv_is_on_batman_iface - check if a device is a batman iface descendant * @net_dev: the device to check * @@ -111,6 +133,9 @@ static bool batadv_is_on_batman_iface(const struct net_device *net_dev) if (WARN(!parent_dev, "Cannot find parent device")) return false; + if (batadv_mutual_parents(net_dev, parent_dev)) + return false; + ret = batadv_is_on_batman_iface(parent_dev); return ret; -- 2.7.0

3 3

[B.A.T.M.A.N.] [PATCH] batman-adv: fix logic error in batadv_v_ogm_forward
by Simon Wunderlich 16 Feb '16

16 Feb '16

From: Simon Wunderlich <simon.wunderlich(a)open-mesh.com> My latest restructure attempt of the BATMAN v forward function introduced a regression, causing kernel crashes when an OGM is forwarded. This patch fixes it. Fixes: 30c96bc787 ("batman-adv: move and restructure batadv_v_ogm_forward") Reported-by: Sven Eckelmann <sven.eckelmann(a)open-mesh.com> Signed-off-by: Simon Wunderlich <simon.wunderlich(a)open-mesh.com> --- net/batman-adv/bat_v_ogm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/bat_v_ogm.c b/net/batman-adv/bat_v_ogm.c index 1b2399e..4155fa5 100644 --- a/net/batman-adv/bat_v_ogm.c +++ b/net/batman-adv/bat_v_ogm.c @@ -309,7 +309,7 @@ static void batadv_v_ogm_forward(struct batadv_priv *bat_priv, u16 tvlv_len; /* only forward for specific interfaces, not for the default one. */ - if (if_outgoing != BATADV_IF_DEFAULT) + if (if_outgoing == BATADV_IF_DEFAULT) goto out; orig_ifinfo = batadv_orig_ifinfo_new(orig_node, if_outgoing); -- 2.7.0

3 2

[B.A.T.M.A.N.] [PATCH 2/4] batman-adv: Speed up dat by snooping received ip traffic
by Andreas Pape 16 Feb '16

16 Feb '16

From cc88159dcf18f4b8310414d2d71635fad76bf5bb Mon Sep 17 00:00:00 2001 From: Andreas Pape <apape(a)phoenixcontact.com> Date: Fri, 12 Feb 2016 11:03:10 +0100 Subject: [PATCH 2/4] batman-adv: Speed up dat by snooping received ip traffic This patch shall speed up dat by snooping all incoming ip traffic instead of only relying on ARP handling. This shall especially increase the probability that a gateway into a backbone network already has a fitting dat entry to answer incoming arp requests directly coming from the backbone network. Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com> --- net/batman-adv/distributed-arp-table.c | 18 ++++++++++++++++++ net/batman-adv/distributed-arp-table.h | 8 +++++++- net/batman-adv/soft-interface.c | 21 ++++++++++++++++++++- 3 files changed, 45 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index 93893bf..4e64e6c 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -362,6 +362,24 @@ 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 + * @ip: ipv4 to add/edit + * @mac_addr: mac address to assign to the given ipv4 + * @vid: VLAN identifier + * + * checks additionally, if dat is enabled. can be called from other modules. + */ +void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip, + u8 *mac_addr, unsigned short vid) +{ + if(!atomic_read(&bat_priv->distributed_arp_table)) + return; + + batadv_dat_entry_add(bat_priv, ip, mac_addr, 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..a2ab16b 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, __be32 ip, + u8 *mac_addr, 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,11 @@ static inline void batadv_dat_inc_counter(struct batadv_priv *bat_priv, { } +void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip, + u8 *mac_addr, 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 0710379..41d7987 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> @@ -390,6 +391,7 @@ void batadv_interface_rx(struct net_device *soft_iface, __be16 ethertype = htons(ETH_P_BATMAN); struct vlan_ethhdr *vhdr; struct ethhdr *ethhdr; + struct iphdr *iphdr; unsigned short vid; bool is_bcast; @@ -412,11 +414,28 @@ void batadv_interface_rx(struct net_device *soft_iface, ethhdr = eth_hdr(skb); switch (ntohs(ethhdr->h_proto)) { + case ETH_P_IP: + iphdr = (struct iphdr *)(skb->data + ETH_HLEN); + /* snoop incoming traffic for dat update using the source mac + * and source ip to speed up dat. + * Question: does this break the fundamental idea of dat???? + */ + batadv_dat_entry_check(bat_priv, iphdr->saddr, ethhdr->h_source, vid); + break; case ETH_P_8021Q: vhdr = (struct vlan_ethhdr *)skb->data; - if (vhdr->h_vlan_encapsulated_proto != ethertype) + if (vhdr->h_vlan_encapsulated_proto != ethertype) { + /* snoop incoming traffic for dat update also for vlan + * tagged frames. + * Question: does this break the fundamental idea of dat???? + */ + if (vhdr->h_vlan_encapsulated_proto == ETH_P_IP) { + iphdr = (struct iphdr *)(vhdr + sizeof(struct vlan_ethhdr)); + batadv_dat_entry_check(bat_priv, iphdr->saddr, vhdr->h_source, vid); + } break; + } /* fall through */ case ETH_P_BATMAN: -- 1.7.0.4 .................................................................. 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. ___________________________________________________________________

2 2

[B.A.T.M.A.N.] [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA setups when DAT does address resolution
by Andreas Pape 16 Feb '16

16 Feb '16

From 2cc1e9eb153d0c2d64cb0fb0747063ba63472925 Mon Sep 17 00:00:00 2001 From: Andreas Pape <apape(a)phoenixcontact.com> Date: Fri, 12 Feb 2016 13:19:25 +0100 Subject: [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA setups when DAT does address resolution This patch covers the case of a bla setup with enabled dat if none of the common gateways of the same backbone has already knowledge of the searched ip address and therefore has to ask via DAT some of the other mesh nodes. A broadcast arp request is coming from the backbone and each backbone gateway starts an address resolution via other DAT mesh nodes. In this case it should be prevented, that multiple answers from DAT enabled mesh nodes reach the backbone gateways leading to multiple replies in a common backbone again. Signed-off-by: Andreas Pape <apape(a)phoenixcontact.com> --- net/batman-adv/distributed-arp-table.c | 56 +++++++++++++++++++++++++++++++- 1 files changed, 55 insertions(+), 1 deletions(-) diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c index 4e64e6c..22976fb 100644 --- a/net/batman-adv/distributed-arp-table.c +++ b/net/batman-adv/distributed-arp-table.c @@ -1080,6 +1080,8 @@ bool batadv_dat_snoop_incoming_arp_request(struct batadv_priv *bat_priv, u8 *hw_src; struct sk_buff *skb_new; struct batadv_dat_entry *dat_entry = NULL; + struct batadv_unicast_4addr_packet *unicast_4addr_packet; + struct batadv_orig_node *orig_node = NULL; bool ret = false; unsigned short vid; int err; @@ -1103,8 +1105,31 @@ bool batadv_dat_snoop_incoming_arp_request(struct batadv_priv *bat_priv, batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid); dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_dst, vid); - if (!dat_entry) + if (!dat_entry) { + /* Check if this is a 4addr unicast DAT_DHT_GET frame from + * another backbone gw of the same backbone. If yes, drop + * it as this leads to multiplication of arp requests in bla setups + * as long as there is no dat_entry fo this answer. In this + * case better drop the DHT_GET. Normal bla code doesn't take care of + * these packets as they are tunneled via unicast. + */ + unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data; + orig_node = batadv_orig_hash_find(bat_priv, unicast_4addr_packet->src); + if (orig_node) { + if ((unicast_4addr_packet->u.packet_type == BATADV_UNICAST_4ADDR) && + (unicast_4addr_packet->subtype == BATADV_P_DAT_DHT_GET) && + (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size))) { + batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP request removed: " + "ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; originator: %pM\n", + hw_src, &ip_src, batadv_arp_hw_dst(skb, hdr_size), &ip_dst, + unicast_4addr_packet->src); + ret = true; + } + batadv_orig_node_put(orig_node); + } + goto out; + } skb_new = arp_create(ARPOP_REPLY, ETH_P_ARP, ip_src, bat_priv->soft_iface, ip_dst, hw_src, @@ -1203,6 +1228,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)) @@ -1222,12 +1248,38 @@ 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. We have + * most probably received already a reply from someone else. 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_check_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 */ @@ -1240,6 +1292,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 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. ___________________________________________________________________

2 2

[B.A.T.M.A.N.] [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by gateways in bla setups with dat enabled
by Andreas Pape 15 Feb '16

15 Feb '16

From 2b90abdf53e9ab09d9acfd141c7225de1ae16719 Mon Sep 17 00:00:00 2001 From: Andreas Pape <apape(a)phoenixcontact.com> Date: Fri, 12 Feb 2016 10:05:57 +0100 Subject: [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by gateways in bla setups with dat enabled This patch shall make 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(a)phoenixcontact.com> --- net/batman-adv/bridge_loop_avoidance.c | 58 ++++++++++++++++++++++++++++++++ net/batman-adv/bridge_loop_avoidance.h | 6 +++ net/batman-adv/distributed-arp-table.c | 14 ++++++++ 3 files changed, 78 insertions(+), 0 deletions(-) diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index 0a6c8b8..c70363d 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -1906,3 +1906,61 @@ out: batadv_hardif_put(primary_if); return 0; } + +/** + * batadv_check_local_claim + * @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 + * + * batadv_check_local_claim: + * addr is checked if this address is claimed by the local device itself. + * If the address is not claimed at all, claim it. + * returns true if bla is disabled or the mac is claimed by the device + * returns false if the device addr is already claimed by another gateway + */ +bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv, uint8_t *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)) { + + 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; + } + } else { + /* If there is no claim, claim the device */ + batadv_dbg(BATADV_DBG_BLA, bat_priv, "No claim found for %pM. Claim mac for us.\n", + search_claim.addr); + + batadv_handle_claim(bat_priv, + primary_if, + primary_if->net_dev->dev_addr, addr, + vid); + } + } + + if (claim) + batadv_claim_put(claim); + if (primary_if) + batadv_hardif_put(primary_if); + return ret; +} diff --git a/net/batman-adv/bridge_loop_avoidance.h b/net/batman-adv/bridge_loop_avoidance.h index 579f0fa..84c31bc 100644 --- a/net/batman-adv/bridge_loop_avoidance.h +++ b/net/batman-adv/bridge_loop_avoidance.h @@ -46,6 +46,7 @@ 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); +bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv, u8 *addr, unsigned short vid); #define BATADV_BLA_CRC_INIT 0 #else /* ifdef CONFIG_BATMAN_ADV_BLA */ @@ -111,6 +112,11 @@ static inline void batadv_bla_free(struct batadv_priv *bat_priv) { } +bool batadv_bla_check_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 e96d7c7..93893bf 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); @@ -1000,6 +1001,19 @@ bool batadv_dat_snoop_outgoing_arp_request(struct batadv_priv *bat_priv, goto out; } + /* If BLA is enabled, only send ARP REPLYs 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_check_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 into common backbone !", + 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 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. ___________________________________________________________________

3 5

[B.A.T.M.A.N.] Antwort: Re: Looping unicast packets when using BLA
by Andreas Pape 15 Feb '16

15 Feb '16

Hi Simon, thanks for the quick reply. Simon Wunderlich <sw(a)simonwunderlich.de> schrieb am 08.02.2016 13:29:55: > Von: Simon Wunderlich <sw(a)simonwunderlich.de> > An: b.a.t.m.a.n(a)lists.open-mesh.org > Kopie: Andreas Pape <APape(a)phoenixcontact.com> > Datum: 09.02.2016 07:20 > Betreff: Re: [B.A.T.M.A.N.] Looping unicast packets when using BLA > > Hi Andreas, > > On Monday 08 February 2016 12:35:35 Andreas Pape wrote: > > Hello > > > > I have a problem in my mesh setup which is quite similiar to Bug#216 of > > the bug tracker. > > I'm using batman-adv 2014.4.0 in a BLA setup consisting of 3 Mesh Nodes > > (A, B, C) connected to the same backone network via a common switch and a > > mesh node D connected to an end device E. I ping that single mesh node D > > and the connected end device E from a PC which is connected to the same > > switch as the three Nodes A to C. BLA is compiled and enabled. > > First of all, did you test v2016.0? v2014.4.0 is pretty old, the bug was > created and closed in 2015 after all ... I just restarted my last year's work to test batman-adv and was a little bit lazy to update to the latests version as my devices use a fairly old kernel version 2.6.32. And the update to 2014.4.0 early last year only worked with Marek's help (issue in the compat code). But before making further assumptions, I'll start with the update first. In the meantime I am pretty sure, that the problem does not come from the bla code as such. I changed the code in batadv_bla_rx in the repsective part as follows: ether_addr_copy(search_claim.addr, ethhdr->h_source); search_claim.vid = vid; claim = batadv_claim_hash_find(bat_priv, &search_claim); if (!claim) { /* possible optimization: race for a claim */ /* No claim exists yet, claim it for us! */ if (!batadv_is_my_client(bat_priv, ethhdr->h_source, vid)) { batadv_handle_claim(bat_priv, primary_if, primary_if->net_dev->dev_addr, ethhdr->h_source, vid); goto allow; } else { printk("not claimed: %pM \n", ethhdr->h_source); goto handled; } } I did this yesterday in a "quick-and-dirty" way and restarted my pingtest, which ran until this morning without looping packets. But I did not notice until now that I did not only prevent the claiming of MAC addresses from the own backbone but I also dropped the packets causing the claim to be triggered! That tells me that the original code in batadv_bla_rx is most likely OK and that my problem comes from somewhere else (e.g. ping request from PC to device E enters gateway A and is forwarded to gateway B via the mesh. But gateway B does not forward it to mesh node D but sends the packet via the linux bridge and my eth0 interface to the backbone network). But before digging deeper into this, I'll make a try with 2016.0 and see if the problem is solved there. > > > > > From time to time I see looping unicast packets in my backbone network. > > This unicast looping starts directly after one of the nodes A to C claimed > > the mac address of my PC. The looping telegram is then the ping request > > sent by the PC. I have a wireshark recording made in my backbone via port > > mirroring of one of the switch ports where a mesh node is connected to > > which shows this behaviour. > > Is it really the ping packet looping? If yes, which nodes are part of the > loop? Normally we only see broadcast packets looping. In #216 it was also > broadcast packets where we have seen duplicates, and this was more a locking > problem leading to creation of the same packets again and again. > > > > > I am not sure if I understood bla correctly but isn't it nonsense that a > > bla backbone gateway claims MAC addresses from its own backbone (i.e. the > > one it is directly connected to via its ethernet port)? > > Yes, that appears to be nonsense indeed. Do you happen to have DAT enabled? > There were also some problems with that which are fixed by now. DAT is enabled. But my problem starts with a gratuitous arp containing a claim and not a multiplication of normal arp requests or repsonses. > > > > > A simple change in batadv_bla_rx seems to solve this problem: add an > > additional check before claiming a new mac address: if this address is > > already known from the tt local table (via command batadv_is_my_client) > > don't claim it. > > > > This seems to solve my problem as far as I have tested so far. Any > > thoughts about that? > > This will prevent roaming from on of your nodes connected to the backbone (A- > C) to the mesh-only node D. > > I would like to suggest to upgrade and test again, and try disabling DAT if > the problem is still present (you should still report it if DAT makes a > difference in that case). If you still see a problem then, we probably have > something unsolved, and then I'd like to understand which nodes are part of > the loop. > > Thank you! > Simon[Anhang "signature.asc" gelöscht von Andreas Pape/Phoenix Contact] Thanks and 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. ___________________________________________________________________

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N February 2016