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 #418 (New): BLA: claiming race condition with multicast from meshhttps://www.open-mesh.org/issues/4182020-09-14T08:54:59ZLinus Lüssinglinus.luessing@c0d3.blue
Scenario:
<ul>
<li>Two BLA backbone gateways sharing the same LAN, receiving a multicast packet from the mesh.</li>
</ul>
Issue:
<ul>
<li>Both BLA backbone gateways will race for a claim. And can end up with both gateways thinking the other one claimed the client. Resulting in packetloss for traffic from the mesh into the BLA backbone.</li>
</ul>
<p>This actually seems to be acknowledged in the code:</p>
<pre><code>1857 if (!claim) {
1858 /* possible optimization: race for a claim */
1859 /* No claim exists yet, claim it for us!
1860 */
</code></pre>
<p><a class="external" href="https://git.open-mesh.org/batman-adv.git/blob/f2a2e0310dc1c570bdd1439553e897649b000292:/net/batman-adv/bridge_loop_avoidance.c#l1858">https://git.open-mesh.org/batman-adv.git/blob/f2a2e0310dc1c570bdd1439553e897649b000292:/net/batman-adv/bridge_loop_avoidance.c#l1858</a></p>
<p>Typically this seems to resolve when the claim times out a bit earlier on one of the BLA backbone gateways. However it unfortunately seems quite persistent when the two nodes were set up on the same host at the same time via a script, for instance. And is probably also persistent when physically similar devices / nodes are booted at the same time, for instance after a power outage.</p>
<p>This should be reproducable with the attached script. It creates a fully meshed topology, with nodes 1 and 2 bridged via LAN, like the following:</p>
<pre><code> --[LAN/br0]--
| |
(1) (2)
| |
---[mesh]----
/ \
(3) ... (8)
</code></pre>
<p>To reproduce, run:</p>
<pre><code>$ ./test-mcast-bla.sh setup
$ ping6 ff12::123%br8
</code></pre>
<p>Then compare <i>"batctl meshif bat1 cl"</i> and <i>"batctl meshif bat2 cl"</i>. You should see that both nodes assume that the other one claimed the MAC from node 8. Furthermore, a <i>"tcpdump -i br0 'icmp6 and dst ff12::123'"</i> should stay silent, showing that the multicasted ICMPv6 Echo Requests are wrongly dropped into the BLA backbone by both node 1 and 2.</p>
<p>You can teardown the test mesh via "$ ./test-mcast-bla.sh teardown" (or restart it via "reload").</p>
<p>Tested in a x86 Debian VM running Linux 5.8.7.</p>
<p>Further notes:</p>
<ul>
<li>Probably more likely to trigger via multicast-to-unicasts than via classic flooding. As the latter adds some jitter on forwarding, making a race less likely.</li>
<li>More likely to trigger if the two BLA backbone gateways are direct neighbors so that they receive the multicast packets at the same time.</li>
</ul> batman-adv - Bug #417 (New): BLA, crash: null pointer dereference in batadv_bla_loopdetect_report...https://www.open-mesh.org/issues/4172020-08-27T08:07:08ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Version:</p>
<pre><code>
$ batctl -v
batctl 2020.2-openwrt-1 [batman-adv: 2020.2-openwrt-1]
</code></pre>
<p>Setup:</p>
<p>8 nodes, 3 of those interconnected on the LAN with BLA. Two of the three LAN devices crashed after about 15 hours with the following trace:</p>
<pre><code>
Time: 1598432655.394152
Modules: pppoe@bf627000+5000 ppp_async@bf61e000+5000 batman_adv@bf5e6000+2c000 ath10k_pci@bf5d5000+b000 ath10k_core@bf55b000+67000 ath@bf552000+6000 pppox@bf54a000+4000 ppp_generic@bf53d000+8000 nft_set_rbtree@bf535000+4000 nft_set_hash@bf52b000+6000 nft_reject_ipv6@bf523000+4000 nft_reject_ipv4@bf51b000+4000 nft_reject_inet@bf513000+4000 nft_reject_bridge@bf50b000+4000 nft_reject@bf504000+4000 nft_redir@bf4fd000+4000 nft_quota@bf4f5000+4000 nft_numgen@bf4ed000+4000 nft_meta_bridge@bf4e5000+4000 nft_meta@bf4dd000+4000 nft_log@bf4d5000+4000 nft_limit@bf4cd000+4000 nft_fwd_netdev@bf4c5000+4000 nft_exthdr@bf4bd000+4000 nft_dup_netdev@bf4b5000+4000 nft_ct@bf4ad000+4000 nft_counter@bf4a5000+4000 nft_chain_route_ipv6@bf49d000+4000 nft_chain_route_ipv4@bf495000+4000 nf_tables_netdev@bf48d000+4000 nf_tables_ipv6@bf485000+4000 nf_tables_ipv4@bf47d000+4000 nf_tables_inet@bf475000+4000 nf_tables_bridge@bf46d000+4000 nf_tables@bf453000+14000 mac80211@bf3ae000+7e000 iptable_nat@bf3a6000+4000 ipt_REJECT@bf39e000+4000 ipt_MASQUERADE@bf396000+4000 cfg80211@bf345000+44000 xt_time@bf33d000+4000 xt_tcpudp@bf335000+4000 xt_tcpmss@bf32d000+4000 xt_statistic@bf325000+4000 xt_state@bf31d000+4000 xt_nat@bf315000+4000 xt_multiport@bf30d000+4000 xt_mark@bf305000+4000 xt_mac@bf2fd000+4000 xt_limit@bf2f5000+4000 xt_length@bf2ed000+4000 xt_hl@bf2e5000+4000 xt_ecn@bf2dd000+4000 xt_dscp@bf2d5000+4000 xt_conntrack@bf2cd000+4000 xt_comment@bf2c5000+4000 xt_TCPMSS@bf2bd000+4000 xt_REDIRECT@bf2b5000+4000 xt_LOG@bf2ad000+4000 xt_HL@bf2a5000+4000 xt_FLOWOFFLOAD@bf29d000+4000 xt_DSCP@bf295000+4000 xt_CLASSIFY@bf28d000+4000 slhc@bf286000+4000 openvswitch@bf265000+1a000 nfnetlink@bf25c000+4000 nf_reject_ipv4@bf255000+4000 nf_nat_redirect@bf24e000+4000 nf_nat_masquerade_ipv6@bf247000+4000 nf_nat_masquerade_ipv4@bf240000+4000 nf_conntrack_ipv6@bf238000+4000 nf_nat_ipv6@bf230000+4000 nf_conntrack_ipv4@bf228000+4000 nf_nat_ipv4@bf220000+4000 nf_nat@bf215000+6000 nf_log_ipv4@bf20d000+4000 nf_flow_table_hw@bf205000+4000 nf_flow_table@bf1fa000+6000 nf_dup_netdev@bf1f3000+4000 nf_defrag_ipv6@bf1eb000+4000 nf_defrag_ipv4@bf1e3000+4000 nf_conntrack_rtcache@bf1db000+4000 nf_conntrack@bf1c2000+11000 libcrc32c@bf1ba000+4000 iptable_mangle@bf1b2000+4000 iptable_filter@bf1aa000+4000 ipt_ECN@bf1a2000+4000 ip_tables@bf198000+6000 crc_ccitt@bf191000+4000 compat@bf188000+5000 ledtrig_usbport@bf180000+4000 nf_log_ipv6@bf178000+4000 nf_log_common@bf170000+4000 ip6table_mangle@bf168000+4000 ip6table_filter@bf160000+4000 ip6_tables@bf156000+6000 ip6t_REJECT@bf14e000+4000 x_tables@bf143000+6000 nf_reject_ipv6@bf13c000+4000 mpls_iptunnel@bf134000+4000 mpls_router@bf128000+7000 mpls_gso@bf120000+4000 leds_gpio@bf118000+4000 xhci_plat_hcd@bf10f000+4000 xhci_pci@bf106000+4000 xhci_hcd@bf0e7000+18000 dwc3@bf0db000+7000 dwc3_of_simple@bf0d3000+4000 ohci_platform@bf0ca000+4000 ohci_hcd@bf0bd000+8000 phy_qcom_dwc3@bf0b5000+4000 ahci@bf0ab000+6000 ehci_platform@bf0a2000+4000 sd_mod@bf094000+9000 ahci_platform@bf08c000+4000 libahci_platform@bf085000+4000 libahci@bf07a000+7000 libata@bf046000+27000 scsi_mod@bf020000+1a000 ehci_hcd@bf010000+b000 gpio_button_hotplug@bf008000+4000 crc32c_generic@bf000000+4000
<3>[ 21.105247] ath10k_pci 0002:01:00.0: DANGER! You're overriding EEPROM-defined regulatory domain
<3>[ 21.105294] ath10k_pci 0002:01:00.0: from: 0x0 to 0x348 (svc-ready-work)
<3>[ 21.112758] ath10k_pci 0002:01:00.0: Your card was not certified to operate in the domain you chose.
<3>[ 21.119792] ath10k_pci 0002:01:00.0: This might result in a violation of your local regulatory rules.
<3>[ 21.128906] ath10k_pci 0002:01:00.0: Do not ever do this unless you really know what you are doing!
<4>[ 21.139581] ath10k_pci 0002:01:00.0: 10.4 wmi init: vdevs: 8 peers: 180 tid: 450
<6>[ 21.146922] ath10k_pci 0002:01:00.0: using 7 firmware rate-ctrl objects
<4>[ 21.154531] ath10k_pci 0002:01:00.0: msdu-desc: 2200 skid: 360
<6>[ 21.237597] ath10k_pci 0002:01:00.0: wmi print 'P 180/180 V 8 K 540 PH 556 T 656 msdu-desc: 2200 sw-crypt: 0 ct-sta: 0'
<6>[ 21.238894] ath10k_pci 0002:01:00.0: wmi print 'free: 11368 iram: 8424 sram: 512'
<6>[ 21.405609] ath10k_pci 0002:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 180 raw 0 hwcrypto 1
<7>[ 21.626332] ath: EEPROM regdomain: 0x8348
<7>[ 21.626345] ath: EEPROM indicates we should expect a country code
<7>[ 21.626364] ath: doing EEPROM country->regdmn map search
<7>[ 21.626377] ath: country maps to regdmn code: 0x3a
<7>[ 21.626391] ath: Country alpha2 being used: US
<7>[ 21.626401] ath: Regpair used: 0x3a
<6>[ 21.638889] batman_adv: B.A.T.M.A.N. advanced 2020.2-openwrt-1 (compatibility version 15) loaded
<14>[ 21.641464] kmodloader: done loading kernel modules from /etc/modules.d/*
<6>[ 24.336245] Atheros 8031 ethernet gpio-0:00: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=gpio-0:00, irq=POLL)
<6>[ 24.337418] dwmac1000: Master AXI performs any burst length
<6>[ 24.346656] ipq806x-gmac-dwmac 37600000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
<6>[ 24.352226] ipq806x-gmac-dwmac 37600000.ethernet eth1: registered PTP clock
<6>[ 24.365549] br-lan: port 1(eth1) entered blocking state
<6>[ 24.367972] br-lan: port 1(eth1) entered disabled state
<6>[ 24.374348] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
<6>[ 24.506123] Atheros 8031 ethernet gpio-0:01: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=gpio-0:01, irq=POLL)
<6>[ 24.513244] dwmac1000: Master AXI performs any burst length
<6>[ 24.516426] ipq806x-gmac-dwmac 37400000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
<6>[ 24.522078] ipq806x-gmac-dwmac 37400000.ethernet eth0: registered PTP clock
<6>[ 24.534347] br-wan: port 1(eth0) entered blocking state
<6>[ 24.537849] br-wan: port 1(eth0) entered disabled state
<6>[ 24.544469] br-wan: port 1(eth0) entered blocking state
<6>[ 24.548271] br-wan: port 1(eth0) entered forwarding state
<6>[ 24.751737] 8021q: adding VLAN 0 to HW filter on device bat0
<6>[ 24.752006] br-lan: port 2(bat0) entered blocking state
<6>[ 24.756560] br-lan: port 2(bat0) entered disabled state
<6>[ 24.761574] device bat0 entered promiscuous mode
<6>[ 24.766771] device eth1 entered promiscuous mode
<6>[ 24.771559] br-lan: port 2(bat0) entered blocking state
<6>[ 24.776138] br-lan: port 2(bat0) entered forwarding state
<6>[ 24.798361] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
<6>[ 25.263219] batman_adv: bat0: No IGMP Querier present - multicast optimizations disabled
<6>[ 25.263251] batman_adv: bat0: No MLD Querier present - multicast optimizations disabled
<6>[ 25.382134] br-wan: port 1(eth0) entered disabled state
<6>[ 27.516892] ipq806x-gmac-dwmac 37600000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx
<4>[ 31.710745] ath10k_pci 0002:01:00.0: 10.4 wmi init: vdevs: 8 peers: 180 tid: 450
<6>[ 31.710774] ath10k_pci 0002:01:00.0: using 7 firmware rate-ctrl objects
<4>[ 31.717361] ath10k_pci 0002:01:00.0: msdu-desc: 2200 skid: 360
<6>[ 31.800345] ath10k_pci 0002:01:00.0: wmi print 'P 180/180 V 8 K 540 PH 556 T 656 msdu-desc: 2200 sw-crypt: 0 ct-sta: 0'
<6>[ 31.801611] ath10k_pci 0002:01:00.0: wmi print 'free: 11368 iram: 8424 sram: 512'
<4>[ 32.193725] ath10k_pci 0002:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
<6>[ 32.193942] IPv6: ADDRCONF(NETDEV_UP): client1: link is not ready
<6>[ 32.208336] br-lan: port 1(eth1) entered blocking state
<6>[ 32.209836] br-lan: port 1(eth1) entered forwarding state
<6>[ 32.237464] br-lan: port 3(client1) entered blocking state
<6>[ 32.237491] br-lan: port 3(client1) entered disabled state
<6>[ 32.242616] device client1 entered promiscuous mode
<6>[ 32.394857] br-wan: port 1(eth0) entered disabled state
<6>[ 32.457821] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
<6>[ 32.762860] ath10k_pci 0002:01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x10000000
<6>[ 32.770474] IPv6: ADDRCONF(NETDEV_CHANGE): client1: link becomes ready
<6>[ 32.771583] br-lan: port 3(client1) entered blocking state
<6>[ 32.777580] br-lan: port 3(client1) entered forwarding state
<6>[ 32.886573] Atheros 8031 ethernet gpio-0:01: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=gpio-0:01, irq=POLL)
<6>[ 32.893172] dwmac1000: Master AXI performs any burst length
<6>[ 32.897375] ipq806x-gmac-dwmac 37400000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
<6>[ 32.902530] ipq806x-gmac-dwmac 37400000.ethernet eth0: registered PTP clock
<6>[ 32.916682] br-wan: port 1(eth0) entered blocking state
<6>[ 32.918477] br-wan: port 1(eth0) entered disabled state
<6>[ 32.928463] IPv6: ADDRCONF(NETDEV_UP): br-wan: link is not ready
<4>[ 38.723594] ath10k_pci 0001:01:00.0: 10.4 wmi init: vdevs: 8 peers: 180 tid: 450
<6>[ 38.723623] ath10k_pci 0001:01:00.0: using 7 firmware rate-ctrl objects
<4>[ 38.731093] ath10k_pci 0001:01:00.0: msdu-desc: 2200 skid: 360
<6>[ 38.811599] ath10k_pci 0001:01:00.0: wmi print 'P 180/180 V 8 K 540 PH 556 T 656 msdu-desc: 2200 sw-crypt: 0 ct-sta: 0'
<6>[ 38.812877] ath10k_pci 0001:01:00.0: wmi print 'free: 11368 iram: 8424 sram: 512'
<4>[ 39.201170] ath10k_pci 0001:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
<6>[ 39.201339] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
<6>[ 39.216274] br-lan: port 4(client0) entered blocking state
<6>[ 39.217340] br-lan: port 4(client0) entered disabled state
<6>[ 39.222873] device client0 entered promiscuous mode
<6>[ 39.528761] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
<6>[ 39.529012] br-lan: port 4(client0) entered blocking state
<6>[ 39.534302] br-lan: port 4(client0) entered forwarding state
<6>[ 40.691860] IPv6: ADDRCONF(NETDEV_UP): mesh0: link is not ready
<6>[ 40.731037] IPv6: ADDRCONF(NETDEV_UP): mesh1: link is not ready
<6>[ 40.823371] ath10k_pci 0001:01:00.0: mac flush null vif, drop 0 queues 0xffff
<6>[ 40.898665] ath10k_pci 0002:01:00.0: mac flush null vif, drop 0 queues 0xffff
<6>[ 41.760998] br-lan: port 4(client0) entered disabled state
<6>[ 41.762528] br-lan: port 3(client1) entered disabled state
<6>[ 44.641968] br-lan: port 3(client1) entered blocking state
<6>[ 44.642010] br-lan: port 3(client1) entered forwarding state
<6>[ 44.649723] batman_adv: bat0: Adding interface: mesh1
<6>[ 44.652216] batman_adv: bat0: Interface activated: mesh1
<6>[ 44.658352] IPv6: ADDRCONF(NETDEV_CHANGE): mesh1: link becomes ready
<4>[ 44.891497] ath10k_pci 0002:01:00.0: Invalid peer id 0 or peer stats buffer, peer: cb915000 sta: (null)
<6>[ 47.250647] br-lan: port 4(client0) entered blocking state
<6>[ 47.250682] br-lan: port 4(client0) entered forwarding state
<6>[ 47.257308] batman_adv: bat0: Adding interface: mesh0
<6>[ 47.260838] batman_adv: bat0: Interface activated: mesh0
<6>[ 47.308240] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
<4>[ 75.993607] NOHZ: local_softirq_pending 08
<4>[ 219.354201] NOHZ: local_softirq_pending 08
<4>[ 444.633812] NOHZ: local_softirq_pending 08
<4>[ 506.073732] NOHZ: local_softirq_pending 08
<4>[ 526.553749] NOHZ: local_softirq_pending 08
<4>[ 669.913737] NOHZ: local_softirq_pending 08
<4>[ 751.833940] NOHZ: local_softirq_pending 08
<4>[ 772.313676] NOHZ: local_softirq_pending 08
<4>[ 792.793586] NOHZ: local_softirq_pending 08
<4>[ 813.273624] NOHZ: local_softirq_pending 08
<4>[ 848.273737] ath10k_pci 0002:01:00.0: peer-unmap-event: unknown peer id 8
<4>[ 850.884255] ath10k_pci 0001:01:00.0: peer-unmap-event: unknown peer id 5
<1>[ 1263.833736] Unable to handle kernel NULL pointer dereference at virtual address 00000038
<1>[ 1263.833770] pgd = c0204000
<1>[ 1263.840947] [00000038] *pgd=00000000
<0>[ 1263.843483] Internal error: Oops: 17 [#1] SMP ARM
<4>[ 1263.847138] Modules linked in: pppoe ppp_async batman_adv ath10k_pci ath10k_core ath pppox ppp_generic nft_set_rbtree nft_set_hash nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject_bridge nft_reject nft_redir nft_quota nft_numgen nft_meta_bridge nft_meta nft_log nft_limit nft_fwd_netdev nft_exthdr nft_dup_netdev nft_ct nft_counter nft_chain_route_ipv6 nft_chain_route_ipv4 nf_tables_netdev nf_tables_ipv6 nf_tables_ipv4 nf_tables_inet nf_tables_bridge nf_tables mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY slhc openvswitch nfnetlink nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv6
<4>[ 1263.901905] nf_nat_masquerade_ipv4 nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_dup_netdev nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack libcrc32c iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 mpls_iptunnel mpls_router mpls_gso leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_of_simple ohci_platform ohci_hcd phy_qcom_dwc3 ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug crc32c_generic
<4>[ 1263.961027] CPU: 0 PID: 2470 Comm: kworker/u4:2 Not tainted 4.14.187 #0
<4>[ 1263.983254] Hardware name: Generic DT based system
<4>[ 1263.989826] Workqueue: bat_events batadv_bla_periodic_work [batman_adv]
<4>[ 1263.994629] task: cbcbed00 task.stack: ca46e000
<4>[ 1264.001153] PC is at batadv_bit_get_packet+0xc4/0xf4 [batman_adv]
<4>[ 1264.005669] LR is at batadv_bit_get_packet+0xb8/0xf4 [batman_adv]
<4>[ 1264.011901] pc : [<bf5ebe30>] lr : [<bf5ebe24>] psr: 60000013
<4>[ 1264.017976] sp : ca46fec0 ip : 000000c8 fp : cd804200
<4>[ 1264.024050] r10: ccd38000 r9 : 00000007 r8 : 00000000
<4>[ 1264.029260] r7 : cb8a64c0 r6 : cb90e300 r5 : cc6f7e8c r4 : 00000000
<4>[ 1264.034471] r3 : 00000038 r2 : 00000002 r1 : 00000000 r0 : cc6f7e8c
<4>[ 1264.041069] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
<4>[ 1264.047578] Control: 10c5787d Table: 4dd7406a DAC: 00000051
<0>[ 1264.054784] Process kworker/u4:2 (pid: 2470, stack limit = 0xca46e210)
<0>[ 1264.060513] Stack: (0xca46fec0 to 0xca470000)
<0>[ 1264.066960] fec0: cc6f7e80 cb90e300 cb90e300 bf5ecbf4 cb95c0c0 00000200 c0b02d00 00000007
<0>[ 1264.071393] fee0: cb8a678c cb8a669c cb90e300 cb8a64c0 cb8a669c 00000000 00000000 00000080
<0>[ 1264.079554] ff00: cd804200 bf5ecd70 cb8a677c cb8a677c 60000013 cb8a669c cb93b080 cd804200
<0>[ 1264.087713] ff20: cbd6c600 00000000 00000000 00000080 cd804200 c0337120 cd804218 ffffe000
<0>[ 1264.095873] ff40: cb93b080 cd804200 cb93b098 cd804218 ffffe000 c0b02d00 00000088 c033761c
<0>[ 1264.104032] ff60: cc72febc ccdd6400 ca46e000 c8fe6880 cc72febc ccdd641c cb93b080 c03372d8
<0>[ 1264.112192] ff80: 00000000 c033d2bc 00000000 c8fe6880 c033d174 00000000 00000000 00000000
<0>[ 1264.120351] ffa0: 00000000 00000000 00000000 c0307d28 00000000 00000000 00000000 00000000
<0>[ 1264.128511] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<0>[ 1264.136670] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
<4>[ 1264.144917] [<bf5ebe30>] (batadv_bit_get_packet [batman_adv]) from [<bf5ecbf4>] (batadv_bla_loopdetect_report+0xa48/0xb44 [batman_adv])
<4>[ 1264.153012] [<bf5ecbf4>] (batadv_bla_loopdetect_report [batman_adv]) from [<bf5ecd70>] (batadv_bla_periodic_work+0x80/0xb04 [batman_adv])
<4>[ 1264.164984] [<bf5ecd70>] (batadv_bla_periodic_work [batman_adv]) from [<c0337120>] (process_one_work+0x28c/0x444)
<4>[ 1264.177456] [<c0337120>] (process_one_work) from [<c033761c>] (worker_thread+0x344/0x58c)
<4>[ 1264.187695] [<c033761c>] (worker_thread) from [<c033d2bc>] (kthread+0x148/0x150)
<4>[ 1264.195860] [<c033d2bc>] (kthread) from [<c0307d28>] (ret_from_fork+0x14/0x2c)
<0>[ 1264.203329] Code: eb4724e3 e5944008 e2843038 f593f000 (e1932f9f)
<4>[ 1264.210463] ---[ end trace 54361f4755dee328 ]---
===========================%
</code></pre> batman-adv - Bug #416 (Feedback): B.A.T.M.A.N. V: include packet loss in link throughput estimationhttps://www.open-mesh.org/issues/4162020-08-21T08:46:18ZAntonio Quartulli
<p><strong>Scenario:</strong><br />I have 2 dual radio APs (1 x 2.4GHz and 1 x 5GHz, both ath10k).<br />The APs are placed in two different rooms with various walls in between. Because of that meshing over 5GHz is quite unreliable.</p>
<p><strong>Problem:</strong><br />Batman-adv is often selecting the route going over the 5GHz radio because the tx rate (used to estimate the throughput) is often higher.<br />This route selection, however, turns out to be a very bad choice because the packet loss makes the 5GHz link unusable (I can hardly ping the other AP with batctl p).</p>
<p>(I wonder though, why is the tx rate often this high if packet loss is high as well...?)</p>
<p><strong>Proposal:</strong><br />One way to mitigate this issue would be to include the packet loss in the 1-hop link throughput estimation logic.<br />Mixing throughput and packet loss can be quite complicated, therefore I would like to keep it simple: i.e. when packet loss over a link is below 50%, drop the throughput to 0.1Mbps.<br />This way that link is heavily penalized and excluded from the routing (unless it's the only choice we have).</p>
<p>To measure the 1-hop packet loss we could either use the OGMs (similarly to what we did in B.A.T.M.A.N. IV, but it may become ugly quite fast) or we could rely on counting the received ELPs and sending back a periodic report to the sender.</p>
<p>Opinions? Comments?</p> 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-130b29e0-show, #collapse-130b29e0-hide').toggle(); $('#collapse-130b29e0').fadeToggle(150);; return false;" id="collapse-130b29e0-show" class="icon icon-collapsed collapsible">See mac address...</a><a href="#" onclick="$('#collapse-130b29e0-show, #collapse-130b29e0-hide').toggle(); $('#collapse-130b29e0').fadeToggle(150);; return false;" id="collapse-130b29e0-hide" class="icon icon-expanded collapsible" style="display:none;">See mac address...</a><div id="collapse-130b29e0" 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-4c30b5e0-show, #collapse-4c30b5e0-hide').toggle(); $('#collapse-4c30b5e0').fadeToggle(150);; return false;" id="collapse-4c30b5e0-show" class="icon icon-collapsed collapsible">See log...</a><a href="#" onclick="$('#collapse-4c30b5e0-show, #collapse-4c30b5e0-hide').toggle(); $('#collapse-4c30b5e0').fadeToggle(150);; return false;" id="collapse-4c30b5e0-hide" class="icon icon-expanded collapsible" style="display:none;">See log...</a><div id="collapse-4c30b5e0" 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 #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> batctl - Feature #353 (New): Translate layer 3 addresses from non Layer 3 neighborshttps://www.open-mesh.org/issues/3532018-04-12T20:24:30ZAndre KasperAndre.Kasper@gmx.de
<p>To me it looks like it is possible to translate macs via dc because batctl is able to view dc. also I guess, that dc content is correct, because elsewhise batman should be broken. So I can't follow why not using it as first source of mac/ip translation and just do the other stuff is this hit doesn't match.</p>
<p>I'm user, not developer. From my perspective it's all about functionality. -i use batctl tr and batctl as an debugging tool. I think this may be the only usecase for this commands. If there is an IP 192.168.4.3 in my network and I would like to find out why und where it is, I would traceroute it. I can't do it with layer 3 tools so I need batctl. It is possible to do it manually. showing and grepping dc and using the mac for tr. from user perspektive it would make much more sense that this would happen also automatically if I translate or traceroute or ping the ip. I can resolve IPs I can't reach via layer2 ping and I can't resolv IPs I can reach via batman. Just from user perspektive and ponyhof I would wish that the debugging functionalities would be able to translate every IP in batman network and don't have a need to translate IPs that are not in batman network (non batman devices maybe could be filtered out?). But seems less a bug issue than a feature request.</p>
<hr />
<p>Original message</p>
<p>If I make batctl tr on a gateway to its own ip the tr goes to wrong mac. also batctl is unable to find mac to other ips.<br />batman 2018.0</p>
<pre>
root@node82:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:08:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.64.1/21 brd 10.110.71.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:208::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::d4a2:a7ff:fe6d:26c5/64 scope link
valid_lft forever preferred_lft forever
root@node82:~# batctl tr 10.110.64.1
traceroute to 10.110.64.1 (72:8e:0a:4d:07:03), 50 hops max, 20 byte packets
1: 02:00:00:02:05:00 0.267 ms 0.144 ms 0.168 ms
2: 4e:70:0a:55:1a:fb 29.208 ms 27.537 ms 28.530 ms
3: 1e:03:61:52:62:93 27.344 ms 26.860 ms 30.777 ms
4: 72:8e:0a:4d:07:03 79.296 ms 75.739 ms 109.504 ms
root@node82:~#
root@node72:~# batctl tr 10.110.56.1
traceroute to 10.110.56.1 (72:8e:0a:4d:07:03), 50 hops max, 20 byte packets
1: 02:00:00:02:05:00 0.256 ms 0.165 ms 0.219 ms
2: 4e:70:0a:55:1a:fb 25.500 ms 25.870 ms 37.836 ms
3: 1e:03:61:52:62:93 29.220 ms 27.655 ms 25.810 ms
4: 72:8e:0a:4d:07:03 77.655 ms 145.679 ms 90.243 ms
root@node72:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:07:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.56.1/21 brd 10.110.63.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:207::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::307c:cbff:fe21:b4e2/64 scope link
valid_lft forever preferred_lft forever
root@node72:~#
root@node52:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:05:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.40.1/21 brd 10.110.47.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:205::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::7c6f:2bff:fe98:a3a9/64 scope link
valid_lft forever preferred_lft forever
root@node52:~# batctl tr 10.110.40.1
traceroute to 10.110.40.1 (aa:a5:39:b1:e3:63), 50 hops max, 20 byte packets
1: 02:00:00:02:06:00 0.243 ms 0.081 ms 0.117 ms
2: aa:a5:39:b1:e3:63 14.457 ms 14.159 ms 11.271 ms
root@node42:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:04:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.32.1/21 brd 10.110.39.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:204::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::acc9:d6ff:fe2b:3968/64 scope link
valid_lft forever preferred_lft forever
root@node42:~# batctl tr 10.110.32.1
traceroute to 10.110.32.1 (72:8e:0a:4d:07:03), 50 hops max, 20 byte packets
1: 02:00:00:02:05:00 0.235 ms 0.263 ms 0.266 ms
2: 4e:70:0a:55:1a:fb 27.696 ms 25.413 ms 27.730 ms
3: 1e:03:61:52:62:93 27.051 ms 29.464 ms 29.175 ms
4: b2:bf:98:e5:c9:bb 26.780 ms 33.047 ms 35.286 ms
5: 72:8e:0a:4d:07:03 * * 28.838 ms
root@node42:~#
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:03:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.24.1/21 brd 10.110.31.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:203::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::8c8e:cff:fe09:6c7c/64 scope link
valid_lft forever preferred_lft forever
root@node32:~# batctl tr 10.110.24.1
traceroute to 10.110.24.1 (aa:a5:39:b1:e3:63), 50 hops max, 20 byte packets
1: 02:00:00:02:06:00 0.209 ms 0.317 ms 0.240 ms
2: aa:a5:39:b1:e3:63 11.947 ms 14.116 ms 13.883 ms
root@node22:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:02:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.16.1/21 brd 10.110.23.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:202::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::7c68:ffff:fe6c:480e/64 scope link
valid_lft forever preferred_lft forever
root@node22:~# batctl tr 10.110.16.1
traceroute to 10.110.16.1 (72:8e:0a:4d:07:03), 50 hops max, 20 byte packets
1: 02:00:00:02:05:00 0.063 ms 0.103 ms 0.098 ms
2: 4e:70:0a:55:1a:fb 27.590 ms 29.041 ms 29.014 ms
3: 1e:03:61:52:62:93 27.610 ms 25.379 ms 27.543 ms
4: b2:bf:98:e5:c9:bb 28.462 ms 32.701 ms 64.105 ms
5: 72:8e:0a:4d:07:03 * 42.850 ms 32.786 ms
root@node12:~# ip a s bat0
5: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 02:00:00:02:01:01 brd ff:ff:ff:ff:ff:ff
inet 10.110.8.1/21 brd 10.110.15.255 scope global bat0
valid_lft forever preferred_lft forever
inet6 2a03:2260:300b:201::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a4cb:6fff:fe9e:a115/64 scope link
valid_lft forever preferred_lft forever
root@node12:~# batctl tr 10.110.8.1
traceroute to 10.110.8.1 (aa:a5:39:b1:e3:63), 50 hops max, 20 byte packets
1: 02:00:00:02:06:00 0.288 ms 0.205 ms 0.189 ms
2: aa:a5:39:b1:e3:63 12.672 ms 14.053 ms 14.329 ms
root@node12:~# batctl tr 10.110.16.1
Error - mac address of the ping destination could not be resolved and is not a bat-host name: 10.110.16.1
root@node12:~# batctl dc |grep 10.110.16.1
* 10.110.16.1 02:00:00:02:02:01 -1 0:11
root@node12:~# batctl dc |grep 10.110.8.1
* 10.110.8.1 02:00:00:02:01:01 -1 0:00
</pre> 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 - 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>