Open Mesh: Issueshttps://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422020-07-22T18:55:01ZOpen Mesh
Redmine batman-adv - Bug #412 (New): general protection fault in batadv_hardif_get_by_netdevhttps://www.open-mesh.org/issues/4122020-07-22T18:55:01ZSven Eckelmann
<pre>
Hello,
syzbot found the following crash on:
HEAD commit: 0aea6d5c Merge tag 'for-linus-5.8b-rc5-tag' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1596004f100000
kernel config: https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=4a2d01c2df834fe6e86d
compiler: gcc (GCC) 10.1.0-syz 20200507
userspace arch: i386
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4a2d01c2df834fe6e86d@syzkaller.appspotmail.com
netlink: 24 bytes leftover after parsing attributes in process `syz-executor.4'.
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 PID: 11316 Comm: syz-executor.4 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:batadv_hardif_get_by_netdev+0x14c/0x400 net/batman-adv/hard-interface.c:72
Code: 18 00 0f 85 92 02 00 00 4d 8b 24 24 49 81 fc e0 29 4f 8d 0f 84 b4 01 00 00 e8 00 01 ab f9 49 8d 7c 24 18 48 89 f8 48 c1 e8 03 <80> 3c 18 00 0f 85 73 02 00 00 4d 39 6c 24 18 75 b7 e8 de 00 ab f9
RSP: 0018:ffffc900171aeca8 EFLAGS: 00010206
RAX: 0000000000000003 RBX: dffffc0000000000 RCX: ffffc90011a8c000
RDX: 0000000000040000 RSI: ffffffff87c8b900 RDI: 0000000000000018
RBP: ffff88802afd4000 R08: 0000000000000000 R09: ffffffff8c593a27
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88802afd4000 R14: 0000000000000000 R15: ffffffff8aa441c0
FS: 0000000000000000(0000) GS:ffff8880ae700000(0063) knlGS:00000000f5d6db40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 000055feecf1dcd8 CR3: 0000000027b29000 CR4: 00000000001426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
batadv_hard_if_event+0x62/0x12f0 net/batman-adv/hard-interface.c:1031
notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027
call_netdevice_notifiers_extack net/core/dev.c:2039 [inline]
call_netdevice_notifiers net/core/dev.c:2053 [inline]
register_netdevice+0xa52/0x1540 net/core/dev.c:9509
veth_newlink+0x405/0xa00 drivers/net/veth.c:1366
__rtnl_newlink+0x1090/0x1730 net/core/rtnetlink.c:3339
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3397
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5460
netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469
netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:672
____sys_sendmsg+0x6e8/0x810 net/socket.c:2352
___sys_sendmsg+0xf3/0x170 net/socket.c:2406
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428
__do_fast_syscall_32 arch/x86/entry/common.c:475 [inline]
do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7f72569
Code: Bad RIP value.
RSP: 002b:00000000f5d6d0cc EFLAGS: 00000296 ORIG_RAX: 0000000000000172
RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 0000000020000040
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
</pre>
<p>See also:</p>
<ul>
<li><a class="external" href="https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/EPSHQY7VW75OYEEU2NAWCIEN7XUM2AKJ/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/EPSHQY7VW75OYEEU2NAWCIEN7XUM2AKJ/</a></li>
</ul> batman-adv - Bug #409 (In Progress): DAT: received packet on bat0.20/eth0 with own address as sou...https://www.open-mesh.org/issues/4092020-04-22T10:48:21ZMatteo Fortini
<p>I have a batman-adv network with four (openwrt 19.07.2) nodes on an 802.11s mesh, two of which are connected by ethernet, too:</p>
<ul>
<li>batman is active on the mesh interface for all nodes, has two VLANs defined (bat0.20 and bat0.107).
<ul>
<li>bat0.20 is the "private" VLAN and is bridged to the ethernet network and a wifi SSID* </li>
</ul>
</li>
<li>bat0.107 is bridged to a secondary wifi SSID</li>
<li>All the bridges have STP off, while batman has bl active
<ul>
<li>batman-adv is correctly finding the backbone and the two wired nodes see each other as neighbors in the bbt.</li>
</ul>
</li>
<li>I changed the MAC address of all wifi interfaces and of the wired ones so that I have no duplicate MAC addresses on the network. <a href="#" onclick="$('#collapse-a5e95946-show, #collapse-a5e95946-hide').toggle(); $('#collapse-a5e95946').fadeToggle(150);; return false;" id="collapse-a5e95946-show" class="icon icon-collapsed collapsible">See mac address...</a><a href="#" onclick="$('#collapse-a5e95946-show, #collapse-a5e95946-hide').toggle(); $('#collapse-a5e95946').fadeToggle(150);; return false;" id="collapse-a5e95946-hide" class="icon icon-expanded collapsible" style="display:none;">See mac address...</a><div id="collapse-a5e95946" class="collapsed-text" style="display:none;"><pre>
bat0 Link encap:Ethernet HWaddr BA:03:29:67:EF:22
bat0.107 Link encap:Ethernet HWaddr BA:03:29:67:EF:22
bat0.20 Link encap:Ethernet HWaddr BA:03:29:67:EF:22
br-IOT Link encap:Ethernet HWaddr 92:83:C4:00:C3:A4
br-pvtlan Link encap:Ethernet HWaddr 96:83:C4:00:C3:98
eth0 Link encap:Ethernet HWaddr 94:83:C4:00:C3:97
eth0.1 Link encap:Ethernet HWaddr 96:83:C4:00:C3:9A
eth0.2 Link encap:Ethernet HWaddr 96:83:C4:00:C3:AA
ifb4pppoe-wan Link encap:Ethernet HWaddr 3E:AB:72:AC:68:E9
mesh0 Link encap:Ethernet HWaddr 92:83:C4:00:C3:A2
wlan0-1 Link encap:Ethernet HWaddr 92:83:C4:00:C3:A0
wlan0-2 Link encap:Ethernet HWaddr 92:83:C4:00:C3:A4
</pre></div></li>
</ul>
<p>In the logs I have every 30s or so the "received packet on bat0.20 with own address..." message.</p>
<p><strong>I can reproduce the problem with DAT enabled, if I disable DAT just on the offending nodes, the problem goes away</strong></p>
<p>Moreover, sometimes the message is repeated much more frequently, as you can see here (the MAC address is unique in all the network):</p>
<p><a href="#" onclick="$('#collapse-1f004b5c-show, #collapse-1f004b5c-hide').toggle(); $('#collapse-1f004b5c').fadeToggle(150);; return false;" id="collapse-1f004b5c-show" class="icon icon-collapsed collapsible">See log...</a><a href="#" onclick="$('#collapse-1f004b5c-show, #collapse-1f004b5c-hide').toggle(); $('#collapse-1f004b5c').fadeToggle(150);; return false;" id="collapse-1f004b5c-hide" class="icon icon-expanded collapsible" style="display:none;">See log...</a><div id="collapse-1f004b5c" class="collapsed-text" style="display:none;"><pre>
Wed Apr 22 10:41:46 2020 [1587552106.093] kern.warn kernel: [59860.042409] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:41:46 2020 [1587552106.094] kern.warn kernel: [59860.053363] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.686] kern.warn kernel: [59922.632640] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.686] kern.warn kernel: [59922.645463] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.699] kern.warn kernel: [59922.659110] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.714] kern.warn kernel: [59922.671797] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.727] kern.warn kernel: [59922.685158] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.739] kern.warn kernel: [59922.698085] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.750] kern.warn kernel: [59922.710141] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.768] kern.warn kernel: [59922.725354] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.781] kern.warn kernel: [59922.740271] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.795] kern.warn kernel: [59922.753516] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.811] kern.warn kernel: [59922.769701] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.837] kern.warn kernel: [59922.784099] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.837] kern.warn kernel: [59922.796203] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.850] kern.warn kernel: [59922.809413] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.905] kern.warn kernel: [59922.852131] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.905] kern.warn kernel: [59922.864420] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.918] kern.warn kernel: [59922.877994] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.933] kern.warn kernel: [59922.891606] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.945] kern.warn kernel: [59922.904572] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.958] kern.warn kernel: [59922.917447] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.972] kern.warn kernel: [59922.930617] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:48 2020 [1587552168.987] kern.warn kernel: [59922.945291] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.000] kern.warn kernel: [59922.959291] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.025] kern.warn kernel: [59922.972003] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.025] kern.warn kernel: [59922.984321] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.038] kern.warn kernel: [59922.997442] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.065] kern.warn kernel: [59923.011990] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.065] kern.warn kernel: [59923.024376] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.079] kern.warn kernel: [59923.038818] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.129] kern.warn kernel: [59923.075739] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.129] kern.warn kernel: [59923.088182] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.142] kern.warn kernel: [59923.101371] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.156] kern.warn kernel: [59923.115845] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.169] kern.warn kernel: [59923.128130] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.180] kern.warn kernel: [59923.140130] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.194] kern.warn kernel: [59923.152668] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:42:49 2020 [1587552169.212] kern.warn kernel: [59923.171584] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:15 2020 [1587552195.951] kern.warn kernel: [59949.906388] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.321] kern.warn kernel: [59950.269484] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.321] kern.warn kernel: [59950.280371] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.601] kern.warn kernel: [59950.546417] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.602] kern.warn kernel: [59950.560768] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.894] kern.warn kernel: [59950.842847] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:16 2020 [1587552196.894] kern.warn kernel: [59950.853728] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:17 2020 [1587552197.033] kern.warn kernel: [59950.982122] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:17 2020 [1587552197.034] kern.warn kernel: [59950.993012] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:19 2020 [1587552199.442] kern.warn kernel: [59953.378814] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:19 2020 [1587552199.453] kern.warn kernel: [59953.389741] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:19 2020 [1587552199.572] kern.warn kernel: [59953.521261] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:20 2020 [1587552200.452] kern.warn kernel: [59954.373032] br-pvtlan: received packet on eth0.2 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:20 2020 [1587552200.452] kern.warn kernel: [59954.383876] br-pvtlan: received packet on eth0.2 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:20 2020 [1587552200.452] kern.warn kernel: [59954.400793] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:20 2020 [1587552200.453] kern.warn kernel: [59954.411769] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.097] kern.warn kernel: [59955.034699] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.097] kern.warn kernel: [59955.045970] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.098] kern.warn kernel: [59955.056856] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.126] kern.warn kernel: [59955.077951] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.275] kern.warn kernel: [59955.124209] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.276] kern.warn kernel: [59955.138702] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.278] kern.warn kernel: [59955.149588] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.279] kern.warn kernel: [59955.163822] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.281] kern.warn kernel: [59955.177733] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.283] kern.warn kernel: [59955.193149] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.284] kern.warn kernel: [59955.204226] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.286] kern.warn kernel: [59955.217875] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.286] kern.warn kernel: [59955.230327] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.300] kern.warn kernel: [59955.259884] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.321] kern.warn kernel: [59955.273602] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:43:21 2020 [1587552201.390] kern.warn kernel: [59955.347076] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:30 2020 [1587552270.575] kern.warn kernel: [60024.523452] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:30 2020 [1587552270.575] kern.warn kernel: [60024.534409] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.098] kern.warn kernel: [60034.045772] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.099] kern.warn kernel: [60034.057617] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.127] kern.warn kernel: [60034.073480] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.127] kern.warn kernel: [60034.086205] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.141] kern.warn kernel: [60034.100187] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.155] kern.warn kernel: [60034.113136] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.167] kern.warn kernel: [60034.126583] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.183] kern.warn kernel: [60034.140927] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.197] kern.warn kernel: [60034.156150] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
Wed Apr 22 10:44:40 2020 [1587552280.220] kern.warn kernel: [60034.177078] br-pvtlan: received packet on bat0.20 with own address as source address (addr:96:83:c4:00:c3:98, vlan:0)
</pre></div></p> batman-adv - Bug #404 (New): KCSAN: data-race in batadv_tt_local_add / batadv_tt_local_addhttps://www.open-mesh.org/issues/4042019-11-08T14:41:24ZSven Eckelmann
<p>The new KCSAN (concurrency sanitizer) reported a problem with the TT code: <a class="external" href="https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/Z44URGZT3NKZP5273KQEMW27WHGNJEUP/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/Z44URGZT3NKZP5273KQEMW27WHGNJEUP/</a></p>
<pre>Hello,
syzbot found the following crash on:
HEAD commit: 05f22368 x86, kcsan: Enable KCSAN for x86
git tree: https://github.com/google/ktsan.git kcsan
console output: https://syzkaller.appspot.com/x/log.txt?x=1195a0d4e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=87d111955f40591f
dashboard link: https://syzkaller.appspot.com/bug?extid=1d5dadec56d9e87f0aac
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1d5dadec56d9e87f0aac@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in batadv_tt_local_add / batadv_tt_local_add
write to 0xffff8880a8e19698 of 2 bytes by task 10064 on cpu 0:
batadv_tt_local_add+0x21b/0x1020 net/batman-adv/translation-table.c:799
batadv_interface_tx+0x398/0xae0 net/batman-adv/soft-interface.c:249
__netdev_start_xmit include/linux/netdevice.h:4420 [inline]
netdev_start_xmit include/linux/netdevice.h:4434 [inline]
xmit_one net/core/dev.c:3280 [inline]
dev_hard_start_xmit+0xef/0x430 net/core/dev.c:3296
__dev_queue_xmit+0x14c9/0x1b60 net/core/dev.c:3873
dev_queue_xmit+0x21/0x30 net/core/dev.c:3906
__bpf_tx_skb net/core/filter.c:2060 [inline]
__bpf_redirect_common net/core/filter.c:2099 [inline]
__bpf_redirect+0x4b4/0x710 net/core/filter.c:2106
____bpf_clone_redirect net/core/filter.c:2139 [inline]
bpf_clone_redirect+0x1a5/0x1f0 net/core/filter.c:2111
bpf_prog_bb15b996d00816f9+0x71c/0x1000
bpf_test_run+0x1c3/0x490 net/bpf/test_run.c:44
bpf_prog_test_run_skb+0x4da/0x840 net/bpf/test_run.c:310
bpf_prog_test_run kernel/bpf/syscall.c:2108 [inline]
__do_sys_bpf+0x1664/0x2b90 kernel/bpf/syscall.c:2884
__se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
__x64_sys_bpf+0x4c/0x60 kernel/bpf/syscall.c:2825
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
read to 0xffff8880a8e19698 of 2 bytes by task 9969 on cpu 1:
batadv_tt_local_add+0x3d1/0x1020 net/batman-adv/translation-table.c:801
batadv_interface_tx+0x398/0xae0 net/batman-adv/soft-interface.c:249
__netdev_start_xmit include/linux/netdevice.h:4420 [inline]
netdev_start_xmit include/linux/netdevice.h:4434 [inline]
xmit_one net/core/dev.c:3280 [inline]
dev_hard_start_xmit+0xef/0x430 net/core/dev.c:3296
__dev_queue_xmit+0x14c9/0x1b60 net/core/dev.c:3873
dev_queue_xmit+0x21/0x30 net/core/dev.c:3906
__bpf_tx_skb net/core/filter.c:2060 [inline]
__bpf_redirect_common net/core/filter.c:2099 [inline]
__bpf_redirect+0x4b4/0x710 net/core/filter.c:2106
____bpf_clone_redirect net/core/filter.c:2139 [inline]
bpf_clone_redirect+0x1a5/0x1f0 net/core/filter.c:2111
bpf_prog_bb15b996d00816f9+0x312/0x1000
bpf_test_run+0x1c3/0x490 net/bpf/test_run.c:44
bpf_prog_test_run_skb+0x4da/0x840 net/bpf/test_run.c:310
bpf_prog_test_run kernel/bpf/syscall.c:2108 [inline]
__do_sys_bpf+0x1664/0x2b90 kernel/bpf/syscall.c:2884
__se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
__x64_sys_bpf+0x4c/0x60 kernel/bpf/syscall.c:2825
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 9969 Comm: syz-executor.2 Not tainted 5.4.0-rc3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
==================================================================
---
This bug 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@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.</pre> batman-adv - Bug #397 (New): BATMAN_V throughput on bridge, vxlan and vethhttps://www.open-mesh.org/issues/3972019-07-29T14:51:36ZLinus Lüssinglinus.luessing@c0d3.blue
<p>For these interfaces, bridge, vxlan and veth, batman-adv currently uses the 1Mbit/s default throughput. Also see:</p>
<p><a class="external" href="https://github.com/freifunk-gluon/gluon/issues/1728">https://github.com/freifunk-gluon/gluon/issues/1728</a></p>
<p>For vxlan Matthias is currently working on a patch to inherit the properties from its parent device (similar to what vlan does).</p>
<p>For veth ethtool reports 10Gbit/s, which is way more reasonable value for an in-kernel connection than our 1MBit/s default value:</p>
<pre><code>$ ethtool veth0
Settings for veth0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Link detected: yes
</code></pre>
<p>However batman-adv uses the default 1MBit/s throughput value due to auto-negotiation being disabled. We could add an exception in batman-adv for veth to disregard the auto-negotiation property, however that would not be sufficient for applications with for instance v(x)lans stacked on top of veth.</p>
<p>For bridge interfaces it is even more tricky.</p> batman-adv - Bug #363 (New): Broadcast ELP smaller than specified in documentionhttps://www.open-mesh.org/issues/3632018-08-31T10:33:46ZSven Eckelmann
<p>Commit a4b88af77e28 ("batman-adv: ELP - adding basic infrastructure") added the ELP broadcast code. It transmits 16 byte ELP packets + 14 byte ethernet header as broadcast to announce itself. The actual <a class="wiki-page" href="https://www.open-mesh.org/projects/batman-adv/wiki/ELP#section-9">specification</a> talks about extra padding to increase the size significantly (300 bytes).</p>
<p>Either the code or the documentation has to be adjusted</p> batman-adv - Bug #360 (Feedback): Batman-adv v2018.1 losst Gateway state after time. https://www.open-mesh.org/issues/3602018-07-08T21:43:34ZJan-Tarek Butttarek@ring0.de
<p>Hi Together,</p>
<a name="Synthom"></a>
<h3 >Synthom:<a href="#Synthom" class="wiki-anchor">¶</a></h3>
<p>After server restart. While some time ago the batman-adv Gateway stop announcing it self.<br />This results int an emty batman-adv Gateway table (see below). Anything else seems working normal.</p>
<a name="System-Info"></a>
<h3 >System Info:<a href="#System-Info" class="wiki-anchor">¶</a></h3>
<p>batctl gwl<br /><pre><code>
[B.A.T.M.A.N. adv 2018.1, MainIF/MAC: mesh-vpn/0a:74:11:ab:7e:27 (bat0/56:1f:85:09:bb:34 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
</code></pre></p>
<p>batctl o<br /><pre><code>
[B.A.T.M.A.N. adv 2018.1, MainIF/MAC: mesh-vpn/0a:74:11:ab:7e:27 (bat0/56:1f:85:09:bb:34 BATMAN_IV)]
Originator last-seen (#/255) Nexthop [outgoingIF]
* 42:de:ae:a6:c4:23 0.787s (224) 46:56:c7:10:61:f3 [ mesh-vpn]
...
</code></pre></p>
<p>batctl -v<br /><code><pre>
batctl 2018.1 [batman-adv: 2018.1]@
</code></pre></p>
<p>batctl -m bat-default gw_mode<br /><code><pre>
server (announced bw: 279.8/120.8 MBit)
</code></pre></p>
<p>uname -a<br /><code><pre>
Linux default02 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 GNU/Linux
</code></pre></p>
<a name="Dynamic-bandwidth-setting"></a>
<h3 >Dynamic bandwidth setting<a href="#Dynamic-bandwidth-setting" class="wiki-anchor">¶</a></h3>
<p>In the background their is a script running which is updating every 30min the (measured - used) bandwidth.<br />Idea behind that: if more traffic is generated by users on this gateway then less bandwidth will be announced and new incoming clients get other gateways with higher announced bandwidth.</p>
<p>Bandwidth updating is done over following code (using batctl):<br /><code><pre>
#!/bin/bash
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings
if [ -z "$1" ]; then
echo
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"
echo
echo "e.g. $0 eth0 60 10 10"
echo
exit
fi
while true
do
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present
# Bandwidth currently used (time averaged)
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")
sleep "$2"
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"
# Remaining bandwidth available; cut-off negative values
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"
else # lockfile present
Tavail_kbitPS=0
Ravail_kbitPS=0
sleep "$2"
fi
for bat in /sys/class/net/bat*; do
iface=${bat##*/}
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
done
done
</code></pre></p>
<a name="Founded-errors"></a>
<h3 >Founded errors:<a href="#Founded-errors" class="wiki-anchor">¶</a></h3>
<p>Attached, I have found some Call traces in the kernel logs which may lead into to the above effects.</p></code></code></code></code> batman-adv - Bug #356 (New): TT: XOR'ing CRC results unsafehttps://www.open-mesh.org/issues/3562018-05-10T12:31:17ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Currently, the custom CRC caluclation for TT in batman-adv works as follows:</p>
<ul>
<li>Compute the CRC for each entry, including vid and TT sync flags.</li>
<li>Then XOR all resulting CRCs</li>
</ul>
<p>However, while playing with injecting flags to multicast entries we now noticed that XOR'ing CRCs seems to possibly have easy collision issues:</p>
<pre><code>root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
01:00:5e:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
* 33:33:ff:5c:79:c9 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
* fe:04:73:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
33:33:00:00:00:01 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
33:33:00:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
01:00:5e:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:ff:5c:79:c9 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* fe:04:73:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
33:33:00:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:ff:5c:79:c9 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* fe:04:73:c8:3a:24 -1 [....] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x#
</code></pre>
<p>When the 'W' flag was injected on node ..:c4 on three of its entries, as expected the result was a new CRC (before: 0xe0acdb32, after: 0x7cf72194).</p>
<p>However, when the 'W' flag was injected on node ..:c3 and only on two of its entries, the CRC stayed the same (0xfefb94e8).</p>
<p>It seems that xor'ing two CRC results which both had exactly the same one bit flipped nullifies the change introduced by this bit.</p>
<p>Sample code to verify:</p>
<pre><code>#!/usr/bin/python3
import binascii
a=b"1234"
b=b"4305"
crca0=binascii.crc32(a, 0x0)
crcb0=binascii.crc32(b, 0x0)
xor0=crca0 ^ crcb0
print('CRC({:s}, 0x0) ^ CRC({:s}, 0x0) = {:#010x} ^ {:#010x} = {:#010x}'.format(str(a), str(b), crca0, crcb0, xor0))
crca1=binascii.crc32(a, 0x1)
crcb1=binascii.crc32(b, 0x1)
xor1=crca1 ^ crcb1
print('CRC({:s}, 0x1) ^ CRC({:s}, 0x1) = {:#010x} ^ {:#010x} = {:#010x}'.format(str(a), str(b), crca1, crcb1, xor1))
</code></pre>
<p>Output:</p>
<pre><code>CRC(b'1234', 0x0) ^ CRC(b'4305', 0x0) = 0x9be3e0a3 ^ 0xf1d519f3 = 0x6a36f950
CRC(b'1234', 0x1) ^ CRC(b'4305', 0x1) = 0x235f87c6 ^ 0x49697e96 = 0x6a36f950
</code></pre>
<p>The reason for XOR'ing instead of only CRC'ing back then seems to have been to be able to be independent of the order of TT entries. Note that any fix by changing the checksumming method batman-adv uses for TT will likely not be backwards compatible.</p> batman-adv - Bug #351 (New): Issues with batadv_gw_out_of_rangehttps://www.open-mesh.org/issues/3512018-03-13T09:25:42ZLinus Lüssinglinus.luessing@c0d3.blue
<p>I'm getting the impression that batadv_gw_out_of_range() is broken or even never worked as intended. gw_out_of_range() is only called if DHCP_TO_SERVER is set in interface_tx(). which is only set to DHCP_TO_SERVER in the is_multicast_ether_addr(ethhdr->h_dest) branch in interface_tx(). However, the kerneldoc for gw_out_of_range() says that for multicast destinations it should always return false which means, DHCP packets to a server would never get dropped in interface_tx() due to being "out-of-range". So clients might have been more sticky to dhcp servers than they should have.</p>
<p>And now with multicast TT entries things might get worse... I think there might be DHCPv4 packetloss if some node were to claim FF:FF:FF:FF:FF:FF via TT (the current multicast code does not announce this. however, a broken or malicious node might). And for DHCPv6, the multicast code will currently announce 33:33:00:01:00:02/33:33:00:01:00:03 so that, DHCPv6, might have become broken with the added multicast code, I suspect.</p> batman-adv - Bug #341 (Feedback): 65% packet loss after node disconnectionhttps://www.open-mesh.org/issues/3412017-07-18T14:28:22ZMoshe Hoorimoshe.hoori@algo.team
<p>Hi,</p>
<p>my configuration is the following :</p>
<pre>
+-------+ +---------------+
|laptop |<---->|batman GateWay |<----> batman nodes(A,B,C)
+-------+ +---------------+
</pre>
<ul>
<li>the laptop is not a part of the batman network. it is connected to the GW via ethernet</li>
<li>all the batman nodes are RocketM5 running batman 2017.1 BATMAN_V</li>
</ul>
<p>scenario :</p>
<ol>
<li>All nodes are connected to batman network.</li>
<li>Node A is shut down</li>
</ol>
<p>the issue:</p>
<p>Ping to node B and C from laptop has about 65% packet loss</p>
<p>Thanks Alot!</p> batman-adv - Feature #339 (New): Make "batctl log" usable with network namespaceshttps://www.open-mesh.org/issues/3392017-07-13T03:09:55ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Currently, this fails as the socket is only available via debugfs right now. And for debugfs we have no namespace support.</p> batman-adv - Feature #291 (New): Reduce DAT Cache misseshttps://www.open-mesh.org/issues/2912016-07-11T08:35:39ZLinus Lüssinglinus.luessing@c0d3.blue
<p>While the overall ARP overhead is greatly reduced, we generally still have many ARP Requests from gateway nodes / routers. In a 1000 node setup this is about 30kbit/s.</p>
<p>In a minimal setup with just two hosts (Linux 4.6-rc6, no batman-adv involved), one being a DHCP server, the other one a DHCP client, as well as one persistent TCP connection between them, I noticed that ARP packets are sent rarely. This seems to break the initial assumption, that at least one ARP exchange would take place during the 5min. DAT cache timeout.</p>
<p>In the test setup, during a ~37000 seconds (10h) interval, these were the only ARP packets showing up:</p>
<pre>
5 106.241867 02:04:64:a4:39:d3 -> ff:ff:ff:ff:ff:ff ARP 60 Who has 192.168.123.1? Tell 192.168.123.50
6 106.241958 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 192.168.123.1 is at 02:04:64:a4:39:f2
14 111.246595 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 Who has 192.168.123.50? Tell 192.168.123.1
15 111.247439 02:04:64:a4:39:d3 -> 02:04:64:a4:39:f2 ARP 60 192.168.123.50 is at 02:04:64:a4:39:d3
2092 5217.550877 02:04:64:a4:39:d3 -> 02:04:64:a4:39:f2 ARP 60 Who has 192.168.123.1? Tell 192.168.123.50
2093 5217.550911 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 192.168.123.1 is at 02:04:64:a4:39:f2
</pre>
<p>Which would of course be insufficient to keep the DAT Cache fully up to date during the time a client is connected.</p> batman-adv - Bug #252 (Feedback): TT: size check before local entry add is incorrect (not threads...https://www.open-mesh.org/issues/2522016-05-15T11:57:50ZSven Eckelmann
<p>Just tested TT with the <a class="wiki-page new" href="https://www.open-mesh.org/projects/open-mesh/wiki/Emulation_Debug">Emulation_Debug</a> environment. Two nodes were enabled and I've just send 3000 packets (different mac addresses) with the attached program to the other node. Then I can see that the remote node sends TT full table requests. But the node which send the 3000 packets never sends the response. The problem seems to be that the tvlv length is 31616 bytes (<code>tvlv_len</code> in batadv_tt_prepare_tvlv_local_data) but this is larger than the maximum packet_size (<code>bat_priv->packet_size_max</code>).</p>
<p>If you print the size check in batadv_tt_local_add right before the <code>if (table_size > packet_size_max) {</code> then you can see that the transmission size jumps (each "foobar" is an add to the local table):</p>
<pre>
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 116 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
foobar 11156 22080
</pre>
<p>The test was started on my node1 via</p>
<pre>
insmod /host/batman-adv/net/batman-adv/batman-adv.ko
/host/batctl/batctl ra BATMAN_IV
/host/batctl/batctl if add eth0
ifconfig eth0 up
ifconfig bat0 up
# sleep 3
/host/batctl/batctl o
/host/rawsend_massive bat0 02:ba:de:af:fe:02
</pre> alfred - Feature #251 (New): batadv-vis: Add support for B.A.T.M.A.N. V throughputhttps://www.open-mesh.org/issues/2512016-05-14T07:54:27ZRussell Seniorrussell@personaltelco.net
<p>I'm experimenting with BATMAN_V on the lede-project revision reboot-231-gf8abb68 with batman-adv and alfred. The batadv-vis program reports:</p>
<p>root@mesh-test1:/# batadv-vis -v<br />batadv-vis 2016.1<br />VIS alfred client</p>
<p>With a three node test network, mesh-test1 and mesh-test2 are linked via both ethernet and wifi ibss mode, mesh-test3 is linked only with wifi, and I get odd looking results from batadv-vis:</p>
<p>root@mesh-test1:/# batadv-vis | grep -v TT<br />digraph {<br /> subgraph "cluster_00:0f:b5:97:28:9d" {<br /> "00:0f:b5:97:28:9d" <br /> "00:0f:b5:0c:e0:84" [peripheries=2]<br /> }<br /> "00:0f:b5:97:28:9d" -> "00:0f:b5:0e:71:5b" [label="2.550"]<br /> "00:0f:b5:0c:e0:84" -> "00:12:cf:83:7b:09" [label="6.711"]<br /> subgraph "cluster_00:0f:b5:0e:5d:8f" {<br /> "00:0f:b5:0e:5d:8f" <br /> "00:0f:b5:0e:71:5b" [peripheries=2]<br /> }<br /> "00:0f:b5:0e:5d:8f" -> "00:12:cf:83:7b:09" [label="6.711"]<br /> "00:0f:b5:0e:71:5b" -> "00:0f:b5:97:28:9d" [label="2.550"]<br />}</p>
<p>The numbers don't seem to ever change, and are way higher than what I would expect from ETX. I'm informed, not surprisingly, that BATMAN_V doesn't use ETX. Whatever metric is used, it might be nice to have it reported.</p> batman-adv - Feature #206 (New): Distributed IPv6-NDP cache to reduce overhead https://www.open-mesh.org/issues/2062015-03-12T15:46:18ZRuben Kelevracyrond@gmail.com
<p>Currently the Neighbor Discovery Protocol does takes much air-time and idle-bandwidth because of the broadcasts which are send thru the network.</p>
<p>It would be nice if the querys could be stored on the nodes, distributed, to use some of ram of the nodes usefully and reduce network overhead.</p>
<p>One possible solution would be:</p>
<ul>
<li>If an IPv6 is queryed by the local client, the node make three hashes and match them to the nearest mac-address of other nodes, and query them.</li>
<li>* If they all send NX do send the query as normal broadcast.</li>
<li>* * If the broadcast get an answer, send an update to the three nodes.</li>
<li>* If they does not return any answers for more than 20 seconds, do a normal broadcast. (redo querys for each Neighbor-Discovery-Query the node get)</li>
<li>If a node get no query for 2h, delete the entry.</li>
<li>If a node get more than $StoreLimit entrys, delete the oldest one.</li>
</ul> batmand - Feature #4 (In Progress): Request: Support iproute2https://www.open-mesh.org/issues/42007-01-21T11:44:47ZAnonymous
<p>Current used version: B.A.T.M.A.N.-III v0.1.1 beta (compability version 2)</p>
<p>I'd like to use batmand without obsolete ip-aliasing.</p>
<p>Example:<br />ip addr add 10.191.1.44/16 brd 10.191.255.255 dev tap0</p>
<p>Suggested Option:<br />batmand tap0 10.191.1.44</p>