Open Mesh: Issueshttps://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422020-10-01T11:49:33ZOpen Mesh
Redmine batman-adv - Bug #420 (New): KMSAN: uninit-value in batadv_nc_workerhttps://www.open-mesh.org/issues/4202020-10-01T11:49:33ZSven Eckelmann
<pre>
Hello,
syzbot found the following issue on:
HEAD commit: 5edb1df2 kmsan: drop the _nosanitize string functions
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=10cc55a7900000
kernel config: https://syzkaller.appspot.com/x/.config?x=4991d22eb136035c
dashboard link: https://syzkaller.appspot.com/bug?extid=da9194708de785081f11
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+da9194708de785081f11@syzkaller.appspotmail.com
=====================================================
BUG: KMSAN: uninit-value in batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:408 [inline]
BUG: KMSAN: uninit-value in batadv_nc_worker+0x1c0/0x1d70 net/batman-adv/network-coding.c:718
CPU: 0 PID: 7 Comm: kworker/u4:0 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_nc_worker
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:122
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:201
batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:408 [inline]
batadv_nc_worker+0x1c0/0x1d70 net/batman-adv/network-coding.c:718
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
kthread+0x551/0x590 kernel/kthread.c:293
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:143 [inline]
kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:126
kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:80
slab_alloc_node mm/slub.c:2907 [inline]
slab_alloc mm/slub.c:2916 [inline]
__kmalloc+0x2bb/0x4b0 mm/slub.c:3982
kmalloc_array+0x90/0x140 include/linux/slab.h:594
batadv_hash_new+0x129/0x530 net/batman-adv/hash.c:52
batadv_originator_init+0x9b/0x370 net/batman-adv/originator.c:211
batadv_mesh_init+0x4dc/0x9d0 net/batman-adv/main.c:204
batadv_softif_init_late+0x6d8/0xa30 net/batman-adv/soft-interface.c:857
register_netdevice+0xbbc/0x37d0 net/core/dev.c:9760
__rtnl_newlink net/core/rtnetlink.c:3454 [inline]
rtnl_newlink+0x2e77/0x3ed0 net/core/rtnetlink.c:3500
rtnetlink_rcv_msg+0x142b/0x18c0 net/core/rtnetlink.c:5563
netlink_rcv_skb+0x6d7/0x7e0 net/netlink/af_netlink.c:2470
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5581
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x11c8/0x1490 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x173a/0x1840 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg net/socket.c:671 [inline]
__sys_sendto+0x9dc/0xc80 net/socket.c:1992
__do_sys_sendto net/socket.c:2004 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:2000
__x64_sys_sendto+0x6e/0x90 net/socket.c:2000
do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
entry_SYSCALL_64_after_hwframe+0x44/0xa9
=====================================================
</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/TFZFXLUH5GYL5NCR4CCAANDB2IPUPIYU/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/TFZFXLUH5GYL5NCR4CCAANDB2IPUPIYU/</a></li>
<li><a class="external" href="https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/HZN6NKEIY6JRCOFXE3O7OGPPUXGBVC3U/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/HZN6NKEIY6JRCOFXE3O7OGPPUXGBVC3U/</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-d86cbdb9-show, #collapse-d86cbdb9-hide').toggle(); $('#collapse-d86cbdb9').fadeToggle(150);; return false;" id="collapse-d86cbdb9-show" class="icon icon-collapsed collapsible">See mac address...</a><a href="#" onclick="$('#collapse-d86cbdb9-show, #collapse-d86cbdb9-hide').toggle(); $('#collapse-d86cbdb9').fadeToggle(150);; return false;" id="collapse-d86cbdb9-hide" class="icon icon-expanded collapsible" style="display:none;">See mac address...</a><div id="collapse-d86cbdb9" 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-3e543cca-show, #collapse-3e543cca-hide').toggle(); $('#collapse-3e543cca').fadeToggle(150);; return false;" id="collapse-3e543cca-show" class="icon icon-collapsed collapsible">See log...</a><a href="#" onclick="$('#collapse-3e543cca-show, #collapse-3e543cca-hide').toggle(); $('#collapse-3e543cca').fadeToggle(150);; return false;" id="collapse-3e543cca-hide" class="icon icon-expanded collapsible" style="display:none;">See log...</a><div id="collapse-3e543cca" 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 #405 (Feedback): No bat0 "tunnel" after STA reassoc - using batman-adv in AP-STA...https://www.open-mesh.org/issues/4052020-01-05T14:57:48ZAnonymous
<p>Hi,</p>
<p>I'm using batman-adv on OpenWrt 19.07-rc.2 on a TP-Link Archer C7 v2 device. First things first, I cannot use wpad-mesh to make a 802.1s device for batman-adv because i need some SSIDs hosted with EAP and that forces me to select the openwrt package "wpad". This one has no 802.1s encrypted mesh support.</p>
<p>I've first tried to add an extra SSID to my radio0 in IBSS ad-hoc mode.<br />Diagram:</p>
<pre>
Device A (AP SSID1, AP SSID2, IBSS SSID for batman-adv) <=> Device B (IBSS SSID for batman-adv)
</pre>
<p>This one worked but brought up a different problem not relevant for here ( see <a class="external" href="https://forum.openwrt.org/t/archer-c7-v2-kernel-warn-comm-wpa-supplicant-not-tainted-4-14-156/51664">https://forum.openwrt.org/t/archer-c7-v2-kernel-warn-comm-wpa-supplicant-not-tainted-4-14-156/51664</a> ).</p>
<p>So I decided to switch to AP and STA combination for batman-adv.<br />Diagram:</p>
<pre>
Device A (AP SSID1, AP SSID2, AP SSID3 for batman-adv) <=> Device B (STA ASSOC to AP SSID3 for batman-adv)
</pre>
<p>The batman-adv "tunnel" comes up fine and the above mentioned kernel.warn's (from IBSS mode) disappear. All fine.</p>
<p>MY PROBLEM:</p>
<ul>
<li>When device A disconnects WiFi clients, e.g. during a reboot, the batman-adv tunnel does NOT come up again by itself. batctl on device B shows that no originator is available anymore. The device B to device A "STA-to-AP" association comes up well after a disconnect.</li>
</ul>
<p>MANUAL FIX:</p>
<ul>
<li>/etc/init.d/network restart</li>
<li>Executed on device B (e.g. from cron if "batctl o" outputs no originators are there)</li>
<li>heals the problem immediately and the batman-adv tunnel works again (verified by pinging)</li>
</ul>
<p>EXPECTATION:</p>
<ul>
<li>If batman-adv is running on a STA interface, e.g. wlan0-3 for my setup, it should automatically do its "internal restart of things" after a STA disconnect and reassociation with the AP without the need for an extra cron job.</li>
</ul>
<p>Thank you for your great work.</p>
<p>I hope this could be fixed or improved in future versions.</p>
<p>Kind regards<br />Catfriend1</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 - Feature #365 (New): Support Jumbo frames via batman-advhttps://www.open-mesh.org/issues/3652018-11-17T16:03:43ZSven Eckelmann
<p>The batadv interface is currently limited to 1500 bytes. There are two reasons why this happens:</p>
<ul>
<li>batadv_softif_init_early doesn't set max_mtu to 0
<ul>
<li>required after Linux 4.10
<ul>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-2-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-2-jarod@redhat.com/</a></li>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-3-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-3-jarod@redhat.com/</a></li>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161020175524.6184-8-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161020175524.6184-8-jarod@redhat.com/</a></li>
</ul>
</li>
</ul>
</li>
<li>batadv_hardif_min_mtu limits it to ETH_DATA_LEN (reason unknown)
<ul>
<li><pre><code class="c syntaxhl" data-language="c"> <span class="cm">/* the real soft-interface MTU is computed by removing the payload
* overhead from the maximum amount of bytes that was just computed.
*
* However batman-adv does not support MTUs bigger than ETH_DATA_LEN
*/</span>
<span class="k">return</span> <span class="nf">min_t</span><span class="p">(</span><span class="kt">int</span><span class="p">,</span> <span class="n">min_mtu</span> <span class="o">-</span> <span class="n">batadv_max_header_len</span><span class="p">(),</span> <span class="n">ETH_DATA_LEN</span><span class="p">);</span>
</code></pre></li>
</ul></li>
</ul>
<p>It has to be checked why this limit was added in the first place, checked whether it can be removed now and then these two functions have to be modified. For kernels < 4.10, an appropriate compat helper has to be added to compat.h.</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 #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 - Bug #333 (Feedback): Compiling 4.11-rc5 fails: "sys/socket.h: No such file or direct...https://www.open-mesh.org/issues/3332017-04-24T18:31:17ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Trying to compile a recent batman-adv master branch with an 4.11-rc5 kernel on a Debian stable currently fails with the following error:</p>
<pre>
/tux/mesh-node/usr/src/linux-headers-4.11.0-rc5+ CONFIG_BATMAN_ADV_BATMAN_V=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_MCAST=y CONFIG_BATMAN_ADV_AGGR=y CONFIG_BATMAN_ADV_NC=n EXTRA_CFLAGS="-Werror -DDEBUG -g -O1"
/home/tux/dev/batman-adv-t_x/gen-compat-autoconf.sh /home/tux/dev/batman-adv-t_x/compat-autoconf.h
mkdir -p /home/tux/dev/batman-adv-t_x/build/net/batman-adv/
compat-patches/replacements.sh
touch /home/tux/dev/batman-adv-t_x/build/net/batman-adv/.compat-prepared
/usr/bin/make -C /home/tux/mesh-node/usr/src/linux-headers-4.11.0-rc5+ M=/home/tux/dev/batman-adv-t_x/build PWD=/home/tux/dev/batman-adv-t_x/build REVISION=2017.0.1-25-ga62cc2a CONFIG_BATMAN_ADV=m CONFIG_BATMAN_ADV_DEBUG=y CONFIG_BATMAN_ADV_DEBUGFS=y CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_NC=n CONFIG_BATMAN_ADV_MCAST=y CONFIG_BATMAN_ADV_BATMAN_V=y INSTALL_MOD_DIR=updates/ modules
make[1]: Entering directory '/home/tux/mesh-node/usr/src/linux-headers-4.11.0-rc5+'
No such file: c
No such file: c
CC [M] /home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o
./include/linux/if.h:27:11: error: unable to open 'sys/socket.h'
In file included from ./include/linux/compat.h:16:0,
from ./include/linux/ethtool.h:16,
from /home/tux/dev/batman-adv-t_x/build/../compat-include/linux/ethtool.h:25,
from ./include/linux/netdevice.h:42,
from /home/tux/dev/batman-adv-t_x/build/../compat-include/linux/netdevice.h:25,
from ./include/linux/icmpv6.h:12,
from ./include/linux/ipv6.h:82,
from /home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.c:36:
./include/linux/if.h:27:54: fatal error: sys/socket.h: No such file or directory
#include <sys/socket.h> /* for struct sockaddr. */
^
compilation terminated.
scripts/Makefile.build:294: recipe for target '/home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o' failed
make[3]: *** [/home/tux/dev/batman-adv-t_x/build/net/batman-adv/../../../compat-sources/net/core/skbuff.o] Error 1
scripts/Makefile.build:553: recipe for target '/home/tux/dev/batman-adv-t_x/build/net/batman-adv' failed
make[2]: *** [/home/tux/dev/batman-adv-t_x/build/net/batman-adv] Error 2
Makefile:1492: recipe for target '_module_/home/tux/dev/batman-adv-t_x/build' failed
make[1]: *** [_module_/home/tux/dev/batman-adv-t_x/build] Error 2
make[1]: Leaving directory '/home/tux/mesh-node/usr/src/linux-headers-4.11.0-rc5+'
Makefile:90: recipe for target 'all' failed
make: *** [all] Error 2
</pre>
<p>The problem was probably introduced with this commit:</p>
<blockquote>
<p>"uapi: fix linux/if.h userspace compilation errors" (<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2618be7dccf8739b89e1906b64bd8d551af351e6" class="external">2618be7dcc</a>)</p>
</blockquote>
<p>Which is part of Linux since 4.11-rc1.</p>
<p>However, it feels like this issue might actually have the root cause in Debian's UAPI header stuff again (<a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: compiling for 4.5 fails: "implicit declaration of function ‘G_TC_AT’" (Closed)" href="https://www.open-mesh.org/issues/322">#322</a>). The batman-adv Make process seems to use "linux-headers-4.11.0-rc5+/include/linux/if.h" which just has the <i>KERNEL</i> guard stripped:</p>
<pre><code>
#ifndef _LINUX_IF_H
#define _LINUX_IF_H
#include <linux/libc-compat.h> /* for compatibility with glibc */
#include <linux/types.h> /* for "__kernel_caddr_t" et al */
#include <linux/socket.h> /* for "struct sockaddr" et al */
/* for "__user" et al */
#include <sys/socket.h> /* for struct sockaddr. */
[...]
</code></pre>
<p>Manually removing this include from the Debian make-kpkg compiled header directory or inserting the "#ifndef <code>__KERNEL__</code>" again helps to compile things again.</p> batman-adv - Feature #310 (New): tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/3102016-11-04T14:38:56ZMartin Weineltmartin@darmstadt.freifunk.net
<pre>
# batctl -m ffda-bat n
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: ffda-vpn/56:a3:b3:8b:aa:e4 (ffda-bat/2a:a9:cb:dd:79:4e BATMAN_IV)]
IF Neighbor last-seen
ffda-vpn da:ff:61:00:05:03 0.240s
ffda-vpn da:ff:61:00:02:03 0.540s
en1 42:f7:31:6f:6c:c8 0.600s
</pre>
<pre>
# batctl -m ffda-bat tp da:ff:61:00:05:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
# batctl -m ffda-bat tp da:ff:61:00:02:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
</pre>
<p>All hosts involved are running batman-adv 2016.4. The local host from where I'm running the tpmeter has the following setup:</p>
<pre>
# ip netns exec ffda ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ffda-bat: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ffda-br state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
3: en1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ffda-bat state UP mode DEFAULT group default qlen 1000
link/ether 00:25:90:0e:66:41 brd ff:ff:ff:ff:ff:ff
4: ffda-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
11: ffda-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel master ffda-bat state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 56:a3:b3:8b:aa:e4 brd ff:ff:ff:ff:ff:ff
</pre><br />where
<ul>
<li>ffda-bat is the batman-adv if</li>
<li>ffda-vpn is a fastd tunnel with 1280 MTU</li>
<li>en1 is a hardlink connecting a local router</li>
<li>ffda-br is a bridge wrapping the ffda-bat if</li>
</ul>
<p>There is no firewalling set up:<br /><pre>
# ip netns exec ffda iptables-save
# Generated by iptables-save v1.6.0 on Fri Nov 4 15:34:37 2016
*filter
:INPUT ACCEPT [17646:4553404]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1482:94244]
COMMIT
# Completed on Fri Nov 4 15:34:37 2016
</pre></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> alfred - Bug #202 (In Progress): Multiple Master Syncing Robustnesshttps://www.open-mesh.org/issues/2022015-01-16T03:34:13ZMartin Weineltmartin@darmstadt.freifunk.net
<p>When using Alfred on quite a lot of nodes the UDP Packages that Alfred sends to sync between masters is getting quite huge. It might therefore trigger fragmentation, and if only one fragment is lost the whole synchronization breaks.</p>
<p>The result is that when requesting data from a master it might result in no data or incomplete data.</p> 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>