B.A.T.M.A.N

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

15 participants
4308 discussions

Re: Passing VID-aware ethernet frames on plain batX interfaces
by Sven Eckelmann 14 Sep '20

14 Sep '20

On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote: > I see. Ok for transmission purposes, but what if I have to receive a tagged > frame? It should not have been send to the other node when there is no TT entry for this mac + VID from the receiver. > Should I only rely to the 8021q interface (eg. bat0.1) or receive the whole > traffic (untagged and tagged) from the plain bat0 interface? Hm? > If this is not feasible, is it possible to handle in someway this? Hm? > A linux > bridge on the top of bat0 interface could make it possible? No, the bridge must also enable the vlan for this bat0 interface. See also https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLAN… Maybe Antonio wants to add more things to this discussion. Kind regards, Sven

4 4

[PATCH] batctl: tcpdump: Fix endianness in ICMPv6 Echo Request/Reply parsing
by Linus Lüssing 13 Sep '20

13 Sep '20

The ICMPv6 Echo Request/Reply sequence number and id as well as the IPv6 header length are two byte long fields and therefore might need a conversion on a little endian system. Otherwise the output will be broken on such a machine. Fixes: 35b37756f4a3 ("add IPv6 support to tcpdump parser") Signed-off-by: Linus Lüssing <linus.luessing(a)c0d3.blue> --- tcpdump.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tcpdump.c b/tcpdump.c index db93681..b9edc20 100644 --- a/tcpdump.c +++ b/tcpdump.c @@ -589,13 +589,15 @@ static void dump_ipv6(unsigned char *packet_buff, ssize_t buff_len, break; case ICMP6_ECHO_REQUEST: printf(" echo request, id: %d, seq: %d, length: %hu\n", - icmphdr->icmp6_id, icmphdr->icmp6_seq, - iphdr->ip6_plen); + ntohs(icmphdr->icmp6_id), + ntohs(icmphdr->icmp6_seq), + ntohs(iphdr->ip6_plen)); break; case ICMP6_ECHO_REPLY: printf(" echo reply, id: %d, seq: %d, length: %hu\n", - icmphdr->icmp6_id, icmphdr->icmp6_seq, - iphdr->ip6_plen); + ntohs(icmphdr->icmp6_id), + ntohs(icmphdr->icmp6_seq), + ntohs(iphdr->ip6_plen)); break; case ICMP6_TIME_EXCEEDED: printf(" time exceeded in-transit, length %zu\n", -- 2.28.0

3 2

Passing VID-aware ethernet frames on plain batX interfaces
by Alessandro Bolletta 11 Sep '20

11 Sep '20

Hi, if I pass tagged ethernet traffic inside a bat0 interface (without creating an alias that uses the linux vlan stack for transparent tagging), is this being allowed by batman-adv?

3 7

general protection fault in batadv_iv_ogm_schedule (2)
by syzbot 10 Sep '20

10 Sep '20

Hello, syzbot found the following issue on: HEAD commit: 34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13db7cdd900000 kernel config: https://syzkaller.appspot.com/x/.config?x=8f5c353182ed6199 dashboard link: https://syzkaller.appspot.com/bug?extid=870c4745cc7a955e17e2 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+870c4745cc7a955e17e2(a)syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 6396 Comm: kworker/u4:8 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet RIP: 0010:batadv_iv_ogm_schedule_buff net/batman-adv/bat_iv_ogm.c:843 [inline] RIP: 0010:batadv_iv_ogm_schedule+0x925/0xf40 net/batman-adv/bat_iv_ogm.c:869 Code: 00 48 c1 e8 03 48 89 44 24 28 48 c7 c5 48 e7 3a 8c 0f 1f 40 00 49 8d 5f 70 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 df e8 7d e0 a9 f9 48 8b 1b 48 b8 00 00 00 RSP: 0018:ffffc90019cd7b88 EFLAGS: 00010202 RAX: 000000000000000e RBX: 0000000000000070 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000007 RDI: 0000000000000000 RBP: ffffffff8c3ae748 R08: ffffffff880ae416 R09: ffffed10152b4c06 R10: ffffed10152b4c06 R11: 0000000000000000 R12: 0000000000000007 R13: ffff8880a95a6028 R14: ffff8880a7f17870 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000931c4000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: batadv_iv_send_outstanding_bat_ogm_packet+0x68c/0x7c0 net/batman-adv/bat_iv_ogm.c:1723 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: ---[ end trace 3bb6c6ec8627e29b ]--- RIP: 0010:batadv_iv_ogm_schedule_buff net/batman-adv/bat_iv_ogm.c:843 [inline] RIP: 0010:batadv_iv_ogm_schedule+0x925/0xf40 net/batman-adv/bat_iv_ogm.c:869 Code: 00 48 c1 e8 03 48 89 44 24 28 48 c7 c5 48 e7 3a 8c 0f 1f 40 00 49 8d 5f 70 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 48 89 df e8 7d e0 a9 f9 48 8b 1b 48 b8 00 00 00 RSP: 0018:ffffc90019cd7b88 EFLAGS: 00010202 RAX: 000000000000000e RBX: 0000000000000070 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000007 RDI: 0000000000000000 RBP: ffffffff8c3ae748 R08: ffffffff880ae416 R09: ffffed10152b4c06 R10: ffffed10152b4c06 R11: 0000000000000000 R12: 0000000000000007 R13: ffff8880a95a6028 R14: ffff8880a7f17870 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000931c4000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

1 0

[PATCH maint v2 0/4] batman-adv: mcast: TT/BLA fixes
by Linus Lüssing 10 Sep '20

10 Sep '20

Hi, These are four fixes for issues which occur when using the batman-adv multicast-to-unicast feature. The first one fixes an issue of an intermediate node snitching multicast-to-unicast packets and either dropping it or rerouting it to another node. Which causes lost packets on some and duplicate packets on other nodes. Patches 2 to 4 fix issues when using the multicast-to-unicast conversion while BLA is enabled and some nodes are sharing the same LAN side. Here it either causes "just" duplicates in the "good" scenario (Patch 4/4). But can also cause multiple BLA backbones to send a frame from the mesh into the same, shared LAN segment (Patch 3). Or in the worst case, even reflect packets back to the host in the shared LAN, which completely confuses switches/bridges and ICMPv6 Neighbor Discovery. Changelog v2: * Adding "Fixes:" lines Regards, Linus

3 15

Running multiple batman-adv namespaces on the same broadcast domain
by Alessandro Bolletta 09 Sep '20

09 Sep '20

Hi everybody, i'm trying to reproduce a PoC where i'm running multiple batman-adv instances(eg. bat0, bat1, batX) on the same broadcast domain. So the scenario is: --- host 1, host 2, host 3 are connected through an ethernet switch, leveraging on a single network card (eth0) each. host 1 runs three batman-adv instances (bat0, bat1, bat2) and each of these instances uses eth0 as member interface Each batman-adv instance lives good on the respecting "namespace" using the same broadcast domain to talk with neighbours. --- Is this kind of scenario supported? Thank you

2 5

Is it possible to send all batman-adv traffic through http proxy cache?
by Chuck Ritola 08 Sep '20

08 Sep '20

Is it possible to send all batman-adv ethernet traffic through an HTTP proxy cache such as Squid? This is for building a fairly large mesh network on amateur radio with some links having limited bandwidth. To improve performance a proxy cache would be installed inside each node, which stores to cache any HTTP responses tagged as cacheable and sniffs for HTTP requests through said switch for requests matching any cache entry. It then blocks the request from being forwarded and responds to the request itself with the cached data. I'm having difficulty figuring out how to get batman-adv to pass all of its raw ethernet traffic (presumably with mesh headers removed) through outside software such as Squid before performing its switching. Another consideration was ALFRED but it doesn't appear to be easily integratable with existing software.

3 3

alfred/batman issue
by Oguzhan Kayhan 08 Sep '20

08 Sep '20

Hello I have two questions which most of you may find very novice. I set up a batman mesh network between 3 nodes..all running B.A.T.M.A.N. adv openwrt-2018.4-0 on batman V protocol. And also installed alfred which version 2016.5 node-1 ( 00:30:1a:4e:aa:20 ) connection IF Neighbor last-seen 00:30:1a:4e:aa:23 0.190s ( 15.8) [ wlan0] 00:30:1a:4e:aa:1d 0.050s ( 8.9) [ wlan0] node-2 ( 00:30:1a:4e:aa:23 ) connection IF Neighbor last-seen 00:30:1a:4e:aa:1d 0.420s ( 22.7) [ wlan0] 00:30:1a:4e:aa:20 0.520s ( 15.8) [ wlan0] node-3 ( 00:30:1a:4e:aa:1d )connection IF Neighbor last-seen 00:30:1a:4e:aa:20 0.500s ( 9.0) [ wlan0] 00:30:1a:4e:aa:23 0.180s ( 22.6) [ wlan0] No clients connected to any of the nodes. Only one of them (node 1) is connected br-wan port to my internal gateway. And all others are reachable via this node (node1) alfred output does not show any neighborhood on this case.. alfred config is ; config 'alfred' 'alfred' option interface 'br-wan' option mode 'master' option batmanif 'bat0' option start_vis '1' option run_facters '1' node-1 digraph { subgraph "cluster_00:30:1a:4e:aa:20" { "00:30:1a:4e:aa:20" } "00:30:1a:4e:aa:20" -> "6c:4b:90:61:e3:d6" [label="TT"] "00:30:1a:4e:aa:20" -> "02:b9:87:a6:4f:66" [label="TT"] "00:30:1a:4e:aa:20" -> "28:d2:44:68:bd:1b" [label="TT"] "00:30:1a:4e:aa:20" -> "90:6c:ac:51:b9:dc" [label="TT"] "00:30:1a:4e:aa:20" -> "34:29:8f:74:59:c9" [label="TT"] "00:30:1a:4e:aa:20" -> "50:7b:9d:56:43:08" [label="TT"] "00:30:1a:4e:aa:20" -> "00:30:1a:4e:aa:21" [label="TT"] "00:30:1a:4e:aa:20" -> "02:b9:87:a6:4f:66" [label="TT"] "00:30:1a:4e:aa:20" -> "00:25:36:c1:13:3a" [label="TT"] "00:30:1a:4e:aa:20" -> "00:24:9b:53:55:62" [label="TT" node-2 digraph { subgraph "cluster_00:30:1a:4e:aa:23" { "00:30:1a:4e:aa:23" } "00:30:1a:4e:aa:23" -> "32:21:1f:29:72:04" [label="TT"] "00:30:1a:4e:aa:23" -> "00:30:1a:4e:aa:24" [label="TT"] "00:30:1a:4e:aa:23" -> "32:21:1f:29:72:04" [label="TT"] } node-3 digraph { subgraph "cluster_00:30:1a:4e:aa:1d" { "00:30:1a:4e:aa:1d" } "00:30:1a:4e:aa:1d" -> "3a:ed:c5:16:bb:e6" [label="TT"] "00:30:1a:4e:aa:1d" -> "00:30:1a:4e:aa:1e" [label="TT"] "00:30:1a:4e:aa:1d" -> "3a:ed:c5:16:bb:e6" [label="TT"] } Even after adding an ethernet client to node 2.. the output replaced as digraph { subgraph "cluster_00:30:1a:4e:aa:23" { "00:30:1a:4e:aa:23" } "00:30:1a:4e:aa:23" -> "32:21:1f:29:72:04" [label="TT"] "00:30:1a:4e:aa:23" -> "00:30:1a:4e:aa:24" [label="TT"] "00:30:1a:4e:aa:23" -> "32:21:1f:29:72:04" [label="TT"] "00:30:1a:4e:aa:23" -> "00:24:9b:53:55:62" [label="TT"] This client traffic is normally passing from eth port of the node-2 to node-3 via wifi, and then node 1 via wifi and then eth of node-1 to internet. but didnt see an update on other nodes even node 1 has all the traffic carrying to the new added client. Is it something expected? Or am I missing something? By the way.. on batctl tg output.. the client appears on the list Client VID Flags Last ttvn Via ttvn (CRC ) * 32:21:1f:29:72:04 0 [....] ( 1) 00:30:1a:4e:aa:23 ( 2) (0x3e5717a8) * 3a:ed:c5:16:bb:e6 -1 [....] ( 1) 00:30:1a:4e:aa:1d ( 1) (0x10f0fbd0) * 00:30:1a:4e:aa:1e -1 [....] ( 1) 00:30:1a:4e:aa:1d ( 1) (0x10f0fbd0) * 3a:ed:c5:16:bb:e6 0 [....] ( 1) 00:30:1a:4e:aa:1d ( 1) (0x2eef010b) * 00:30:1a:4e:aa:24 -1 [....] ( 1) 00:30:1a:4e:aa:23 ( 2) (0xcfe8055b) * 32:21:1f:29:72:04 -1 [....] ( 1) 00:30:1a:4e:aa:23 ( 2) (0xcfe8055b) * 00:24:9b:53:55:62 -1 [....] ( 2) 00:30:1a:4e:aa:23 ( 2) (0xcfe8055b) Second question is valid only after I see the neighborhood information correct.. Which tool can I use on openwrt to visualize this relation between nodes.Any ready tools for luci? Regards

2 1

Node amount restriction in IEEE 802.11s mesh network
by Maksim Iushchenko 02 Sep '20

02 Sep '20

I read that IEEE 802.11s mesh network has a restriction for how many nodes it consists of. It is supposed that the number of nodes in IEEE 802.11s mesh network does not exceed 32 nodes or so. Is it HWMP protocol restriction? Or what is it related to? If I turn HWMP off and use batman-adv instead, could it overcome such restriction?

2 1

[PATCH maint 1/4] batman-adv: mcast/TT: fix wrongly dropped or rerouted packets
by Linus Lüssing 01 Sep '20

01 Sep '20

The unicast packet rerouting code makes several assumptions. For instance it assumes that there is always exactly one destination in the TT. This breaks for multicast frames in a unicast packets in several ways: For one thing if there is actually no TT entry and the destination node was selected due to the multicast tvlv flags it announced. Then an intermediate node will wrongly drop the packet. For another thing if there is a TT entry but the TTVN of this entry is newer than the originally addressed destination node: Then the intermediate node will wrongly redirect the packet, leading to duplicated multicast packets at a multicast listener and missing packets at other multicast listeners or multicast routers. Fixing this by not applying the unicast packet rerouting to batman-adv unicast packets with a multicast payload. We are not able to detect a roaming multicast listener at the moment and will just continue to send the multicast frame to both the new and old destination for a while in case of such a roaming multicast listener. Signed-off-by: Linus Lüssing <linus.luessing(a)c0d3.blue> --- net/batman-adv/routing.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c index 27cdf5e4..9e5c71e4 100644 --- a/net/batman-adv/routing.c +++ b/net/batman-adv/routing.c @@ -826,6 +826,10 @@ static bool batadv_check_unicast_ttvn(struct batadv_priv *bat_priv, vid = batadv_get_vid(skb, hdr_len); ethhdr = (struct ethhdr *)(skb->data + hdr_len); + /* do not reroute multicast frames in a unicast header */ + if (is_multicast_ether_addr(ethhdr->h_dest)) + return true; + /* check if the destination client was served by this node and it is now * roaming. In this case, it means that the node has got a ROAM_ADV * message and that it knows the new destination in the mesh to re-route -- 2.28.0

1 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N