Open Mesh: Issueshttps://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422021-04-20T09:49:13ZOpen Mesh
Redmine batman-adv - Bug #422 (New): General protection fault in batadv_orig_router_gethttps://www.open-mesh.org/issues/4222021-04-20T09:49:13ZLinus Lüssinglinus.luessing@c0d3.blue
<p>In a VM with kvm and a 5.11.9 kernel and a recent batman-adv from the master branch I get a general protection fault when putting the VM host to sleep and waking it up again later. The VM guest runs a few mesh instances (here bat1 to bat8).</p>
<p>Looks like some race condition where the orig node is deleted due to timeout but there is still an OGM in the queue from this node for further processing. Without putting a node in stand-by this seems unlikely to happen as when a node timeouts then there typically will be no OGM in the queue.</p>
<pre><code>
[308421.793525] batman_adv: bat3: IGMP Querier disappeared - multicast optimizations disabled
[308421.795414] batman_adv: bat3: MLD Querier disappeared - multicast optimizations disabled
[308421.801542] batman_adv: bat6: IGMP Querier disappeared - multicast optimizations disabled
[308421.802905] batman_adv: bat6: MLD Querier disappeared - multicast optimizations disabled
[308421.804257] batman_adv: bat5: IGMP Querier disappeared - multicast optimizations disabled
[308421.805761] batman_adv: bat5: MLD Querier disappeared - multicast optimizations disabled
[308421.813031] batman_adv: bat4: IGMP Querier disappeared - multicast optimizations disabled
[308421.814303] batman_adv: bat4: MLD Querier disappeared - multicast optimizations disabled
[308421.815716] batman_adv: bat2: IGMP Querier disappeared - multicast optimizations disabled
[308421.816779] batman_adv: bat2: MLD Querier disappeared - multicast optimizations disabled
[308421.819384] batman_adv: bat8: IGMP Querier disappeared - multicast optimizations disabled
[308421.820670] batman_adv: bat8: MLD Querier disappeared - multicast optimizations disabled
[308421.821942] batman_adv: bat7: IGMP Querier disappeared - multicast optimizations disabled
[308421.823706] batman_adv: bat7: MLD Querier disappeared - multicast optimizations disabled
[308422.813967] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP PTI
[308422.816150] CPU: 0 PID: 12563 Comm: kworker/u2:1 Tainted: G OE 5.11.9 #41
[308422.818045] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
[308422.819949] Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet [batman_adv]
[308422.821797] RIP: 0010:batadv_orig_router_get+0x10/0x70 [batman_adv]
[308422.823032] Code: 03 00 00 00 4c 89 c7 e9 de d9 0d ea 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 41 54 48 8b 47 08 48 85 c0 74 0e <48> 39 70 10 74 16 48 8b 00 48 85 c0 75 f2 45 31 e4 e8 0a f2 d9
[308422.826658] RSP: 0018:ffffa0d140003d50 EFLAGS: 00010202
[308422.827700] RAX: 6b6b6b6b6b6b6b6b RBX: ffff90a4c7b2104e RCX: 000000000000000b
[308422.829049] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff90a4c4e68400
[308422.830400] RBP: ffff90a4c0763bd8 R08: ffff90a4c008e8c0 R09: 00000000000002c0
[308422.831759] R10: ffff90a4c7b21000 R11: 0000000000000001 R12: ffff90a4c008e878
[308422.833103] R13: ffff90a4c7b21040 R14: 0000000000000000 R15: 0000000000000001
[308422.834425] FS: 0000000000000000(0000) GS:ffff90a4cde00000(0000) knlGS:0000000000000000
[308422.835926] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[308422.836984] CR2: 00007ffced2d6000 CR3: 0000000009cde000 CR4: 00000000000006f0
[308422.838301] Call Trace:
[308422.838789] <IRQ>
[308422.839318] batadv_iv_ogm_process_per_outif+0x261/0xff0 [batman_adv]
[308422.840332] ? enqueue_entity+0x163/0x760
[308422.841867] batadv_iv_ogm_receive+0x26a/0x4a0 [batman_adv]
[308422.842560] batadv_batman_skb_recv+0x117/0x1d0 [batman_adv]
[308422.843357] __netif_receive_skb_one_core+0x8e/0xa0
[308422.844492] process_backlog+0x96/0x160
[308422.845036] net_rx_action+0x146/0x430
[308422.845594] __do_softirq+0xc5/0x275
[308422.846510] asm_call_irq_on_stack+0x12/0x20
[308422.847059] </IRQ>
[308422.847348] do_softirq_own_stack+0x37/0x40
[308422.848588] do_softirq+0x5e/0x70
[308422.849420] __local_bh_enable_ip+0x4b/0x50
[308422.850164] __dev_queue_xmit+0x376/0x8b0
[308422.850989] batadv_send_skb_packet+0xcc/0xf0 [batman_adv]
[308422.851950] batadv_iv_send_outstanding_bat_ogm_packet+0x18d/0x1b0 [batman_adv]
[308422.853154] process_one_work+0x1ec/0x380
[308422.853946] worker_thread+0x53/0x3e0
[308422.854566] ? process_one_work+0x380/0x380
[308422.855276] kthread+0x11b/0x140
[308422.855827] ? __kthread_bind_mask+0x60/0x60
[308422.856577] ret_from_fork+0x22/0x30
[308422.857199] Modules linked in: batman_adv(OE) bridge(OE) veth(E) dummy(E) libcrc32c(E) crc32c_generic(E) crc32_generic(E) crc16(E) mac80211(E) cfg80211(E) rfkill(E) libarc4(E) stp(E) llc(E) rpcsec_gss_krb5(E]
[308422.867669] ---[ end trace 3d57397987128d5a ]---
[308422.868423] RIP: 0010:batadv_orig_router_get+0x10/0x70 [batman_adv]
[308422.869429] Code: 03 00 00 00 4c 89 c7 e9 de d9 0d ea 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 41 54 48 8b 47 08 48 85 c0 74 0e <48> 39 70 10 74 16 48 8b 00 48 85 c0 75 f2 45 31 e4 e8 0a f2 d9
[308422.872321] RSP: 0018:ffffa0d140003d50 EFLAGS: 00010202
[308422.873143] RAX: 6b6b6b6b6b6b6b6b RBX: ffff90a4c7b2104e RCX: 000000000000000b
[308422.874270] RDX: 000000000000000a RSI: 0000000000000000 RDI: ffff90a4c4e68400
[308422.875433] RBP: ffff90a4c0763bd8 R08: ffff90a4c008e8c0 R09: 00000000000002c0
[308422.876548] R10: ffff90a4c7b21000 R11: 0000000000000001 R12: ffff90a4c008e878
[308422.877735] R13: ffff90a4c7b21040 R14: 0000000000000000 R15: 0000000000000001
[308422.878778] FS: 0000000000000000(0000) GS:ffff90a4cde00000(0000) knlGS:0000000000000000
[308422.880257] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[308422.881197] CR2: 00007ffced2d6000 CR3: 0000000009cde000 CR4: 00000000000006f0
[308422.882512] Kernel panic - not syncing: Fatal exception in interrupt
[308422.884049] Kernel Offset: 0x29600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[308422.886580] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
</code></pre> batman-adv - Bug #421 (New): Misconfig or bug: received packet on bat0 with own address as source...https://www.open-mesh.org/issues/4212020-10-28T15:06:47ZAdrian Schmutzler
<a name="General-setup"></a>
<h2 >General setup:<a href="#General-setup" class="wiki-anchor">¶</a></h2>
<p>Freifunk Franken firmware fork, where Batman is used on a distributed Layer-2 network connected to gateways via fastd tunnels.</p>
<p>Each node offers client and mesh via ethernet (e.g. via vlans, eth0.1 for client and eth0.3 for mesh) and via WiFi (e.g. w2ap for 2.4 GHz AP und w2mesh for 2.4 GHz mesh (802.11s), w5ap for 5 GHz AP etc.)<br />We make sure that all of the "mesh" interfaces (e.g. eth0.3, w2mesh, w5mesh, i.e. what you see with batctl if) have distinct MAC addresses.<br />Same for all "client" interfaces, i.e. members of the same bridge br-mesh alongside bat0 (e.g. eth0.1, w2ap, w5ap)</p>
<p>MAC addresses are allowed to overlap <em>between</em> those groups, though, e.g. eth0.3 (="mesh") could have the same address as w2ap (="client/ap").</p>
<a name="Test-setup"></a>
<h2 >Test setup:<a href="#Test-setup" class="wiki-anchor">¶</a></h2>
<p>Isolated device configured as above and connected to Freifunk network via layer-3 (WAN), i.e. no batman neighbors ("batctl o" and "batctl n" are empty).<br />Device is acting as batman server (gw_mode server), but similar behavior can be produced with batman client nodes. BLA is active (=default).<br />TP-Link TL-WDR4900 v1<br />OpenWrt 19.07 (Tested with .3 on the device, the problem itself is present across all subversions including .4 observed on different devices)<br />Batman-adv openwrt-2019.2-7 (openwrt-routing 19.07 branch; I also tested with the recent 2019.2-10 including a recent BLA patch on a different device)</p>
<a name="Problem"></a>
<h2 >Problem:<a href="#Problem" class="wiki-anchor">¶</a></h2>
<p>dmesg (and logread) show the following every 10 seconds:</p>
<pre>
[ 179.939430] br-mesh: received packet on bat0 with own address as source address (addr:fa:1a:67:xx:xx:fb, vlan:0)
</pre>
<a name="Discussion"></a>
<h2 >Discussion:<a href="#Discussion" class="wiki-anchor">¶</a></h2>
<p>I can remove the warning via one of two measures:</p>
<ol>
<li>Remove the MAC address collision of eth0.3 ("mesh") and w5ap ("client") by giving an arbitrary unique MAC address to eth0.3</li>
<li>Disable BLA via uci set network.bat0.bridge_loop_avoidance='0'</li>
</ol>
<a name="Actual-question"></a>
<h2 >Actual question:<a href="#Actual-question" class="wiki-anchor">¶</a></h2>
<p>From my conceptual understanding, I do not see a reason why an overlap between "client" and "mesh" MAC addresses should be forbidden.<br />Actually, it's quite strange that particularly the overlap of eth0.3 ("mesh") and w5ap ("client") causes the warning, while the still existing overlap between eth0.1 ("client") and w5mesh ("mesh") is <em>not</em> harmful.</p>
<p>Therefore, my actual question is: is this intended behavior, i.e. is this MAC overlap actually forbidden? Or this is a bug (possibly caused/created by BLA)?<br />Keep in mind that this happens on an isolated device.</p>
<p>As a consequence, since disabling BLA removes the warning, would disabling BLA "solve" the problem then for the moment, since the packets sent by BLA are the root cause, or would disabling BLA just remove a detection tool for the misconfiguration that still exists?</p>
<a name="Further-info"></a>
<h2 >Further info:<a href="#Further-info" class="wiki-anchor">¶</a></h2>
<p>MAC addresses:</p>
<pre>
bat0: random
br-mesh: f8:...:fb
eth0: f8:...:fb (same as eth0.1)
eth0.2: f8:...:fc
eth0.3: fa:...:fb
w2ap: fa:...:fa
w2mesh: f8:...:fa
w5ap: fa:...:fb
w5mesh: f8:...:fb
</pre>
<p>(There are additional AP networks configured, but those have separate addresses and also are completely separate from batman)</p>
<p>OpenWrt network config:</p>
<pre>
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdff:0::/64'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_eth0_2_dev'
option name 'eth0.2'
option macaddr 'f8:1a:67:xx:xx:fc'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan 'vlan1'
option device 'switch0'
option vlan '1'
option ports '0t 1t 4 5'
config switch_vlan 'vlan2'
option device 'switch0'
option vlan '2'
option ports '0t 1t'
config interface 'eth0_3'
option proto 'batadv_hardif'
option master 'bat0'
option ifname 'eth0.3'
config interface 'mesh'
option type 'bridge'
option auto '1'
option ifname 'bat0 eth0.1'
option macaddr 'f8:1a:67:xx:xx:fb'
list ip6addr 'fdff:0::0:f81a:67xx:xxfb/64'
...
option proto 'static'
list ipaddr '10.xx.xx.1/24'
option ip4table 'fff'
option ip6table 'fff'
config switch_vlan 'vlan3'
option device 'switch0'
option vlan '3'
option ports '0t 1t 2 3'
config device 'ethmesh_dev'
option name 'eth0.3'
option macaddr 'fa:1a:67:xx:xx:fb'
config interface 'w5mesh'
option mtu '1560'
option proto 'batadv_hardif'
option master 'bat0'
config interface 'configap5'
option proto 'static'
option ip6addr 'fe80::1/64'
config interface 'w2mesh'
option mtu '1560'
option proto 'batadv_hardif'
option master 'bat0'
config interface 'configap2'
option proto 'static'
option ip6addr 'fe80::1/64'
config interface 'bat0'
option proto 'batadv'
option gw_mode 'server'
option gw_sel_class '200000'
option network_coding '0'
option network_coding '0'
option aggregated_ogms '1'
option ap_isolation '0'
option bonding '0'
option fragmentation '1'
option orig_interval '1000'
option distributed_arp_table '1'
option hop_penalty '30'
# followed by various rules and wireguard interfaces
</pre> 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 #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 #411 (New): general protection fault in batadv_iv_ogm_schedule_buff (2)https://www.open-mesh.org/issues/4112020-07-07T20:04:28ZSven Eckelmann
<pre>
Hello,
syzbot found the following crash on:
HEAD commit: 7cc2a8ea Merge tag 'block-5.8-2020-07-01' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130b828f100000
kernel config: https://syzkaller.appspot.com/x/.config?x=7be693511b29b338
dashboard link: https://syzkaller.appspot.com/bug?extid=2eeeb5ad0766b57394d8
compiler: gcc (GCC) 10.1.0-syz 20200507
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+2eeeb5ad0766b57394d8@syzkaller.appspotmail.com
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 9126 Comm: kworker/u4:9 Not tainted 5.8.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
RIP: 0010:batadv_iv_ogm_schedule_buff+0xd1e/0x1410 net/batman-adv/bat_iv_ogm.c:843
Code: 80 3c 28 00 0f 85 ee 05 00 00 4d 8b 3f 49 81 ff e0 e9 4e 8d 0f 84 dd 02 00 00 e8 bd 80 ae f9 49 8d 7f 70 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 af 06 00 00 48 8b 44 24 08 49 8b 6f 70 80 38
RSP: 0018:ffffc90004e97b98 EFLAGS: 00010202
RAX: 000000000000000e RBX: ffff8880a7471800 RCX: ffffffff87c5394d
RDX: ffff88804cf02380 RSI: ffffffff87c536a3 RDI: 0000000000000070
RBP: 0000000000077000 R08: 0000000000000001 R09: ffff8880a875a02b
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000007
R13: dffffc0000000000 R14: ffff888051ad4c40 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000400200 CR3: 0000000061cac000 CR4: 00000000001426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
batadv_iv_ogm_schedule net/batman-adv/bat_iv_ogm.c:869 [inline]
batadv_iv_ogm_schedule net/batman-adv/bat_iv_ogm.c:862 [inline]
batadv_iv_send_outstanding_bat_ogm_packet+0x5c8/0x800 net/batman-adv/bat_iv_ogm.c:1722
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Modules linked in:
---[ end trace f5c5eda032070cd1 ]---
RIP: 0010:batadv_iv_ogm_schedule_buff+0xd1e/0x1410 net/batman-adv/bat_iv_ogm.c:843
Code: 80 3c 28 00 0f 85 ee 05 00 00 4d 8b 3f 49 81 ff e0 e9 4e 8d 0f 84 dd 02 00 00 e8 bd 80 ae f9 49 8d 7f 70 48 89 f8 48 c1 e8 03 <42> 80 3c 28 00 0f 85 af 06 00 00 48 8b 44 24 08 49 8b 6f 70 80 38
RSP: 0018:ffffc90004e97b98 EFLAGS: 00010202
RAX: 000000000000000e RBX: ffff8880a7471800 RCX: ffffffff87c5394d
RDX: ffff88804cf02380 RSI: ffffffff87c536a3 RDI: 0000000000000070
RBP: 0000000000077000 R08: 0000000000000001 R09: ffff8880a875a02b
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000007
R13: dffffc0000000000 R14: ffff888051ad4c40 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000400200 CR3: 000000009480d000 CR4: 00000000001426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
</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/thread/XBVBFSLNCT73H2AELGD4Y7HRMZU5C4EX/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/thread/XBVBFSLNCT73H2AELGD4Y7HRMZU5C4EX/</a></li>
<li><a class="external" href="https://groups.google.com/forum/#!msg/syzkaller-lts-bugs/L9X3uBxeRLQ/w0SggdN7AAAJ">https://groups.google.com/forum/#!msg/syzkaller-lts-bugs/L9X3uBxeRLQ/w0SggdN7AAAJ</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/thread/JFEOUTPZP7GTO73PX7I47JJX2XX2EX4Y/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/thread/JFEOUTPZP7GTO73PX7I47JJX2XX2EX4Y/</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-9a5788e6-show, #collapse-9a5788e6-hide').toggle(); $('#collapse-9a5788e6').fadeToggle(150);; return false;" id="collapse-9a5788e6-show" class="icon icon-collapsed collapsible">See mac address...</a><a href="#" onclick="$('#collapse-9a5788e6-show, #collapse-9a5788e6-hide').toggle(); $('#collapse-9a5788e6').fadeToggle(150);; return false;" id="collapse-9a5788e6-hide" class="icon icon-expanded collapsible" style="display:none;">See mac address...</a><div id="collapse-9a5788e6" 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-6a973709-show, #collapse-6a973709-hide').toggle(); $('#collapse-6a973709').fadeToggle(150);; return false;" id="collapse-6a973709-show" class="icon icon-collapsed collapsible">See log...</a><a href="#" onclick="$('#collapse-6a973709-show, #collapse-6a973709-hide').toggle(); $('#collapse-6a973709').fadeToggle(150);; return false;" id="collapse-6a973709-hide" class="icon icon-expanded collapsible" style="display:none;">See log...</a><div id="collapse-6a973709" 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 - Bug #399 (New): batman-adv complains about MTU in cases where it is not necessarily.https://www.open-mesh.org/issues/3992019-09-30T15:41:48ZМарк Коренбергsocketpair@gmail.com
<p>According to current code, it complains if MTU is less than 1560 if NC was enabled during compilation.</p>
<ol>
<li>If I have compiled with NC on but did not enable NC at runtime, set MTU to 1532, batman complains and this annoys me. Please fix the code to check if runtime NC settings before complainig to choose correct constant. It also should show a message when NC state is changed by user at runtime.</li>
<li>This complaining does not respect 802.1q VLAN. In order VLANs to work, MTU should be 4 bytes more. i.e. instead of 1532 (or 1560) it should be 1536 (or 1564). Possibly, the kernel should complain about this only if someone adds vlan interface above bat0.</li>
</ol> 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 #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 #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 - 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 - 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>