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 #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-10e64d2e-show, #collapse-10e64d2e-hide').toggle(); $('#collapse-10e64d2e').fadeToggle(150);; return false;" id="collapse-10e64d2e-show" class="icon icon-collapsed collapsible">See mac address...</a><a href="#" onclick="$('#collapse-10e64d2e-show, #collapse-10e64d2e-hide').toggle(); $('#collapse-10e64d2e').fadeToggle(150);; return false;" id="collapse-10e64d2e-hide" class="icon icon-expanded collapsible" style="display:none;">See mac address...</a><div id="collapse-10e64d2e" 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-4c5a9ca1-show, #collapse-4c5a9ca1-hide').toggle(); $('#collapse-4c5a9ca1').fadeToggle(150);; return false;" id="collapse-4c5a9ca1-show" class="icon icon-collapsed collapsible">See log...</a><a href="#" onclick="$('#collapse-4c5a9ca1-show, #collapse-4c5a9ca1-hide').toggle(); $('#collapse-4c5a9ca1').fadeToggle(150);; return false;" id="collapse-4c5a9ca1-hide" class="icon icon-expanded collapsible" style="display:none;">See log...</a><div id="collapse-4c5a9ca1" 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 - Feature #365 (New): Support Jumbo frames via batman-advhttps://www.open-mesh.org/issues/3652018-11-17T16:03:43ZSven Eckelmann
<p>The batadv interface is currently limited to 1500 bytes. There are two reasons why this happens:</p>
<ul>
<li>batadv_softif_init_early doesn't set max_mtu to 0
<ul>
<li>required after Linux 4.10
<ul>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-2-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-2-jarod@redhat.com/</a></li>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-3-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161008020434.9691-3-jarod@redhat.com/</a></li>
<li><a class="external" href="https://patchwork.ozlabs.org/project/netdev/patch/20161020175524.6184-8-jarod@redhat.com/">https://patchwork.ozlabs.org/project/netdev/patch/20161020175524.6184-8-jarod@redhat.com/</a></li>
</ul>
</li>
</ul>
</li>
<li>batadv_hardif_min_mtu limits it to ETH_DATA_LEN (reason unknown)
<ul>
<li><pre><code class="c syntaxhl" data-language="c"> <span class="cm">/* the real soft-interface MTU is computed by removing the payload
* overhead from the maximum amount of bytes that was just computed.
*
* However batman-adv does not support MTUs bigger than ETH_DATA_LEN
*/</span>
<span class="k">return</span> <span class="nf">min_t</span><span class="p">(</span><span class="kt">int</span><span class="p">,</span> <span class="n">min_mtu</span> <span class="o">-</span> <span class="n">batadv_max_header_len</span><span class="p">(),</span> <span class="n">ETH_DATA_LEN</span><span class="p">);</span>
</code></pre></li>
</ul></li>
</ul>
<p>It has to be checked why this limit was added in the first place, checked whether it can be removed now and then these two functions have to be modified. For kernels < 4.10, an appropriate compat helper has to be added to compat.h.</p> batman-adv - Bug #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 - Feature #310 (New): tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/3102016-11-04T14:38:56ZMartin Weineltmartin@darmstadt.freifunk.net
<pre>
# batctl -m ffda-bat n
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: ffda-vpn/56:a3:b3:8b:aa:e4 (ffda-bat/2a:a9:cb:dd:79:4e BATMAN_IV)]
IF Neighbor last-seen
ffda-vpn da:ff:61:00:05:03 0.240s
ffda-vpn da:ff:61:00:02:03 0.540s
en1 42:f7:31:6f:6c:c8 0.600s
</pre>
<pre>
# batctl -m ffda-bat tp da:ff:61:00:05:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
# batctl -m ffda-bat tp da:ff:61:00:02:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
</pre>
<p>All hosts involved are running batman-adv 2016.4. The local host from where I'm running the tpmeter has the following setup:</p>
<pre>
# ip netns exec ffda ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ffda-bat: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ffda-br state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
3: en1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ffda-bat state UP mode DEFAULT group default qlen 1000
link/ether 00:25:90:0e:66:41 brd ff:ff:ff:ff:ff:ff
4: ffda-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
11: ffda-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel master ffda-bat state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 56:a3:b3:8b:aa:e4 brd ff:ff:ff:ff:ff:ff
</pre><br />where
<ul>
<li>ffda-bat is the batman-adv if</li>
<li>ffda-vpn is a fastd tunnel with 1280 MTU</li>
<li>en1 is a hardlink connecting a local router</li>
<li>ffda-br is a bridge wrapping the ffda-bat if</li>
</ul>
<p>There is no firewalling set up:<br /><pre>
# ip netns exec ffda iptables-save
# Generated by iptables-save v1.6.0 on Fri Nov 4 15:34:37 2016
*filter
:INPUT ACCEPT [17646:4553404]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1482:94244]
COMMIT
# Completed on Fri Nov 4 15:34:37 2016
</pre></p> batman-adv - 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>