Open Mesh: Issueshttps://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422020-09-14T09:24:08ZOpen Mesh
Redmine batman-adv - Feature #419 (New): BLA: redundant and superficial GW checkhttps://www.open-mesh.org/issues/4192020-09-14T09:24:08ZLinus Lüssinglinus.luessing@c0d3.blue
<p>The source address check in batadv_recv_unicast_packet() here is both superficial and redundant:</p>
<pre><code> 989 /* packet for me */
990 if (batadv_is_my_mac(bat_priv, unicast_packet->dest)) {
991 /* If this is a unicast packet from another backgone gw,
992 * drop it.
993 */
994 orig_addr_gw = eth_hdr(skb)->h_source;
995 orig_node_gw = batadv_orig_hash_find(bat_priv, orig_addr_gw);
996 if (orig_node_gw) {
997 is_gw = batadv_bla_is_backbone_gw(skb, orig_node_gw,
998 hdr_size);
999 batadv_orig_node_put(orig_node_gw);
1000 if (is_gw) {
1001 batadv_dbg(BATADV_DBG_BLA, bat_priv,
1002 "%s(): Dropped unicast pkt received from another backbone gw %pM.\n",
1003 __func__, orig_addr_gw);
1004 goto free_skb;
1005 }
1006 }
1007
</code></pre>
<p><a class="external" href="https://git.open-mesh.org/batman-adv.git/blob/f2a2e0310dc1c570bdd1439553e897649b000292:/net/batman-adv/routing.c#l1000">https://git.open-mesh.org/batman-adv.git/blob/f2a2e0310dc1c570bdd1439553e897649b000292:/net/batman-adv/routing.c#l1000</a></p>
<p>Redundant, because the sender is already supposed to perform this check, so no need to do it again on reception.</p>
Superficial, because it only works if:
<ul>
<li>The BLA backbone gateway we share a LAN with is a direct neighbor of us.</li>
<li>The BLA backbone gateway we share a LAN with transmits the packet via its primary interface to us.</li>
</ul>
<p>In all other cases, like received via multiple hops or via a secondary interface from the other BLA gateway does not work.</p>
Suggestion:
<ul>
<li>Either remove this check.</li>
<li>Or turn the according batadv_dbg() into a pr_warn_ratelimited() to help in spotting potential bugs</li>
</ul>
<p>(This check initially made it hard to reproduce the issue this patch is supposed to fix: <a class="external" href="https://patchwork.open-mesh.org/project/b.a.t.m.a.n./patch/20200914012136.5278-2-linus.luessing@c0d3.blue/">https://patchwork.open-mesh.org/project/b.a.t.m.a.n./patch/20200914012136.5278-2-linus.luessing@c0d3.blue/</a>. Initially it was easy to reproduce in a physical setup but then difficult to reproduce in a virtual one, because they had different configurations regarding primary vs. secondary interfaces.)</p> batman-adv - Feature #414 (New): Replace usage of word slave/masterhttps://www.open-mesh.org/issues/4142020-07-24T06:29:56ZSven Eckelmann
<p>The code uses the word "slave" in various places. These <a href="https://www.kernel.org/doc/html/v5.8-rc6/process/coding-style.html#naming" class="external">terms are considered deprecated</a> by (parts of) the kernel community.</p>
<p>I agree that there might be better words to describe the relationship of the batadv and attached (lower) devices. But the network subsystem has to be changed first to use these terms before we can switch to the new functions (and connected terminology). And due to this problem, I have disabled the checks for DEPRECATED_TERM in the daily build_test for now.</p>
<p>The ticket should be therefore worked on after the related code in net/core/rtnetlink.c was adjusted.</p> batman-adv - Bug #412 (New): general protection fault in batadv_hardif_get_by_netdevhttps://www.open-mesh.org/issues/4122020-07-22T18:55:01ZSven Eckelmann
<pre>
Hello,
syzbot found the following crash on:
HEAD commit: 0aea6d5c Merge tag 'for-linus-5.8b-rc5-tag' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1596004f100000
kernel config: https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=4a2d01c2df834fe6e86d
compiler: gcc (GCC) 10.1.0-syz 20200507
userspace arch: i386
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4a2d01c2df834fe6e86d@syzkaller.appspotmail.com
netlink: 24 bytes leftover after parsing attributes in process `syz-executor.4'.
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 PID: 11316 Comm: syz-executor.4 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:batadv_hardif_get_by_netdev+0x14c/0x400 net/batman-adv/hard-interface.c:72
Code: 18 00 0f 85 92 02 00 00 4d 8b 24 24 49 81 fc e0 29 4f 8d 0f 84 b4 01 00 00 e8 00 01 ab f9 49 8d 7c 24 18 48 89 f8 48 c1 e8 03 <80> 3c 18 00 0f 85 73 02 00 00 4d 39 6c 24 18 75 b7 e8 de 00 ab f9
RSP: 0018:ffffc900171aeca8 EFLAGS: 00010206
RAX: 0000000000000003 RBX: dffffc0000000000 RCX: ffffc90011a8c000
RDX: 0000000000040000 RSI: ffffffff87c8b900 RDI: 0000000000000018
RBP: ffff88802afd4000 R08: 0000000000000000 R09: ffffffff8c593a27
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88802afd4000 R14: 0000000000000000 R15: ffffffff8aa441c0
FS: 0000000000000000(0000) GS:ffff8880ae700000(0063) knlGS:00000000f5d6db40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 000055feecf1dcd8 CR3: 0000000027b29000 CR4: 00000000001426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
batadv_hard_if_event+0x62/0x12f0 net/batman-adv/hard-interface.c:1031
notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027
call_netdevice_notifiers_extack net/core/dev.c:2039 [inline]
call_netdevice_notifiers net/core/dev.c:2053 [inline]
register_netdevice+0xa52/0x1540 net/core/dev.c:9509
veth_newlink+0x405/0xa00 drivers/net/veth.c:1366
__rtnl_newlink+0x1090/0x1730 net/core/rtnetlink.c:3339
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3397
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5460
netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469
netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:672
____sys_sendmsg+0x6e8/0x810 net/socket.c:2352
___sys_sendmsg+0xf3/0x170 net/socket.c:2406
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428
__do_fast_syscall_32 arch/x86/entry/common.c:475 [inline]
do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7f72569
Code: Bad RIP value.
RSP: 002b:00000000f5d6d0cc EFLAGS: 00000296 ORIG_RAX: 0000000000000172
RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 0000000020000040
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
</pre>
<p>See also:</p>
<ul>
<li><a class="external" href="https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/EPSHQY7VW75OYEEU2NAWCIEN7XUM2AKJ/">https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/EPSHQY7VW75OYEEU2NAWCIEN7XUM2AKJ/</a></li>
</ul> batman-adv - Bug #399 (New): batman-adv complains about MTU in cases where it is not necessarily.https://www.open-mesh.org/issues/3992019-09-30T15:41:48ZМарк Коренбергsocketpair@gmail.com
<p>According to current code, it complains if MTU is less than 1560 if NC was enabled during compilation.</p>
<ol>
<li>If I have compiled with NC on but did not enable NC at runtime, set MTU to 1532, batman complains and this annoys me. Please fix the code to check if runtime NC settings before complainig to choose correct constant. It also should show a message when NC state is changed by user at runtime.</li>
<li>This complaining does not respect 802.1q VLAN. In order VLANs to work, MTU should be 4 bytes more. i.e. instead of 1532 (or 1560) it should be 1536 (or 1564). Possibly, the kernel should complain about this only if someone adds vlan interface above bat0.</li>
</ol> batman-adv - Bug #397 (New): BATMAN_V throughput on bridge, vxlan and vethhttps://www.open-mesh.org/issues/3972019-07-29T14:51:36ZLinus Lüssinglinus.luessing@c0d3.blue
<p>For these interfaces, bridge, vxlan and veth, batman-adv currently uses the 1Mbit/s default throughput. Also see:</p>
<p><a class="external" href="https://github.com/freifunk-gluon/gluon/issues/1728">https://github.com/freifunk-gluon/gluon/issues/1728</a></p>
<p>For vxlan Matthias is currently working on a patch to inherit the properties from its parent device (similar to what vlan does).</p>
<p>For veth ethtool reports 10Gbit/s, which is way more reasonable value for an in-kernel connection than our 1MBit/s default value:</p>
<pre><code>$ ethtool veth0
Settings for veth0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Link detected: yes
</code></pre>
<p>However batman-adv uses the default 1MBit/s throughput value due to auto-negotiation being disabled. We could add an exception in batman-adv for veth to disregard the auto-negotiation property, however that would not be sufficient for applications with for instance v(x)lans stacked on top of veth.</p>
<p>For bridge interfaces it is even more tricky.</p> batman-adv - 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 #356 (New): TT: XOR'ing CRC results unsafehttps://www.open-mesh.org/issues/3562018-05-10T12:31:17ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Currently, the custom CRC caluclation for TT in batman-adv works as follows:</p>
<ul>
<li>Compute the CRC for each entry, including vid and TT sync flags.</li>
<li>Then XOR all resulting CRCs</li>
</ul>
<p>However, while playing with injecting flags to multicast entries we now noticed that XOR'ing CRCs seems to possibly have easy collision issues:</p>
<pre><code>root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
01:00:5e:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
* 33:33:ff:5c:79:c9 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
* fe:04:73:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
33:33:00:00:00:01 -1 [....] ( 2) 02:01:64:a4:39:c4 ( 2) (0xe0acdb32)
33:33:00:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
01:00:5e:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:ff:5c:79:c9 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* fe:04:73:c8:3a:24 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
33:33:00:00:00:01 -1 [....] ( 2) 02:84:64:a4:39:c3 ( 2) (0xfefb94e8)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x# batctl tg
[B.A.T.M.A.N. adv 2018.1-10-gc0c5f610, MainIF/MAC: ens3/02:32:64:a4:39:c1 (bat0/0a:f0:8e:ca:5e:82 BATMAN_IV)]
Client VID Flags Last ttvn Via ttvn (CRC )
* 0e:b3:20:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:0c:05:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
01:00:5e:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 01:00:5e:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
* 33:33:ff:c8:3a:24 -1 [....] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
* 4a:1d:5e:5c:79:c9 -1 [....] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:ff:5c:79:c9 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* fe:04:73:c8:3a:24 -1 [....] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:84:64:a4:39:c3 ( 4) (0xfefb94e8)
33:33:00:00:00:01 -1 [.W..] ( 4) 02:01:64:a4:39:c4 ( 4) (0x7cf72194)
* 33:33:00:00:00:01 -1 [....] ( 2) 02:05:64:a4:39:c2 ( 2) (0xdbb13619)
root@Linus-Debian:/mnt/batman-adv-t_x#
</code></pre>
<p>When the 'W' flag was injected on node ..:c4 on three of its entries, as expected the result was a new CRC (before: 0xe0acdb32, after: 0x7cf72194).</p>
<p>However, when the 'W' flag was injected on node ..:c3 and only on two of its entries, the CRC stayed the same (0xfefb94e8).</p>
<p>It seems that xor'ing two CRC results which both had exactly the same one bit flipped nullifies the change introduced by this bit.</p>
<p>Sample code to verify:</p>
<pre><code>#!/usr/bin/python3
import binascii
a=b"1234"
b=b"4305"
crca0=binascii.crc32(a, 0x0)
crcb0=binascii.crc32(b, 0x0)
xor0=crca0 ^ crcb0
print('CRC({:s}, 0x0) ^ CRC({:s}, 0x0) = {:#010x} ^ {:#010x} = {:#010x}'.format(str(a), str(b), crca0, crcb0, xor0))
crca1=binascii.crc32(a, 0x1)
crcb1=binascii.crc32(b, 0x1)
xor1=crca1 ^ crcb1
print('CRC({:s}, 0x1) ^ CRC({:s}, 0x1) = {:#010x} ^ {:#010x} = {:#010x}'.format(str(a), str(b), crca1, crcb1, xor1))
</code></pre>
<p>Output:</p>
<pre><code>CRC(b'1234', 0x0) ^ CRC(b'4305', 0x0) = 0x9be3e0a3 ^ 0xf1d519f3 = 0x6a36f950
CRC(b'1234', 0x1) ^ CRC(b'4305', 0x1) = 0x235f87c6 ^ 0x49697e96 = 0x6a36f950
</code></pre>
<p>The reason for XOR'ing instead of only CRC'ing back then seems to have been to be able to be independent of the order of TT entries. Note that any fix by changing the checksumming method batman-adv uses for TT will likely not be backwards compatible.</p> 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 #351 (New): Issues with batadv_gw_out_of_rangehttps://www.open-mesh.org/issues/3512018-03-13T09:25:42ZLinus Lüssinglinus.luessing@c0d3.blue
<p>I'm getting the impression that batadv_gw_out_of_range() is broken or even never worked as intended. gw_out_of_range() is only called if DHCP_TO_SERVER is set in interface_tx(). which is only set to DHCP_TO_SERVER in the is_multicast_ether_addr(ethhdr->h_dest) branch in interface_tx(). However, the kerneldoc for gw_out_of_range() says that for multicast destinations it should always return false which means, DHCP packets to a server would never get dropped in interface_tx() due to being "out-of-range". So clients might have been more sticky to dhcp servers than they should have.</p>
<p>And now with multicast TT entries things might get worse... I think there might be DHCPv4 packetloss if some node were to claim FF:FF:FF:FF:FF:FF via TT (the current multicast code does not announce this. however, a broken or malicious node might). And for DHCPv6, the multicast code will currently announce 33:33:00:01:00:02/33:33:00:01:00:03 so that, DHCPv6, might have become broken with the added multicast code, I suspect.</p> batman-adv - Feature #339 (New): Make "batctl log" usable with network namespaceshttps://www.open-mesh.org/issues/3392017-07-13T03:09:55ZLinus Lüssinglinus.luessing@c0d3.blue
<p>Currently, this fails as the socket is only available via debugfs right now. And for debugfs we have no namespace support.</p> batman-adv - Feature #310 (New): tpmeter: convert any provided address to proper originator addresshttps://www.open-mesh.org/issues/3102016-11-04T14:38:56ZMartin Weineltmartin@darmstadt.freifunk.net
<pre>
# batctl -m ffda-bat n
[B.A.T.M.A.N. adv 2016.4, MainIF/MAC: ffda-vpn/56:a3:b3:8b:aa:e4 (ffda-bat/2a:a9:cb:dd:79:4e BATMAN_IV)]
IF Neighbor last-seen
ffda-vpn da:ff:61:00:05:03 0.240s
ffda-vpn da:ff:61:00:02:03 0.540s
en1 42:f7:31:6f:6c:c8 0.600s
</pre>
<pre>
# batctl -m ffda-bat tp da:ff:61:00:05:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
# batctl -m ffda-bat tp da:ff:61:00:02:03
Test duration 10110ms.
Sent 0 Bytes.
Throughput: 0 Bytes/s (0 Bps)
</pre>
<p>All hosts involved are running batman-adv 2016.4. The local host from where I'm running the tpmeter has the following setup:</p>
<pre>
# ip netns exec ffda ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ffda-bat: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ffda-br state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
3: en1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ffda-bat state UP mode DEFAULT group default qlen 1000
link/ether 00:25:90:0e:66:41 brd ff:ff:ff:ff:ff:ff
4: ffda-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
11: ffda-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel master ffda-bat state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 56:a3:b3:8b:aa:e4 brd ff:ff:ff:ff:ff:ff
</pre><br />where
<ul>
<li>ffda-bat is the batman-adv if</li>
<li>ffda-vpn is a fastd tunnel with 1280 MTU</li>
<li>en1 is a hardlink connecting a local router</li>
<li>ffda-br is a bridge wrapping the ffda-bat if</li>
</ul>
<p>There is no firewalling set up:<br /><pre>
# ip netns exec ffda iptables-save
# Generated by iptables-save v1.6.0 on Fri Nov 4 15:34:37 2016
*filter
:INPUT ACCEPT [17646:4553404]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1482:94244]
COMMIT
# Completed on Fri Nov 4 15:34:37 2016
</pre></p> batman-adv - Feature #291 (New): Reduce DAT Cache misseshttps://www.open-mesh.org/issues/2912016-07-11T08:35:39ZLinus Lüssinglinus.luessing@c0d3.blue
<p>While the overall ARP overhead is greatly reduced, we generally still have many ARP Requests from gateway nodes / routers. In a 1000 node setup this is about 30kbit/s.</p>
<p>In a minimal setup with just two hosts (Linux 4.6-rc6, no batman-adv involved), one being a DHCP server, the other one a DHCP client, as well as one persistent TCP connection between them, I noticed that ARP packets are sent rarely. This seems to break the initial assumption, that at least one ARP exchange would take place during the 5min. DAT cache timeout.</p>
<p>In the test setup, during a ~37000 seconds (10h) interval, these were the only ARP packets showing up:</p>
<pre>
5 106.241867 02:04:64:a4:39:d3 -> ff:ff:ff:ff:ff:ff ARP 60 Who has 192.168.123.1? Tell 192.168.123.50
6 106.241958 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 192.168.123.1 is at 02:04:64:a4:39:f2
14 111.246595 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 Who has 192.168.123.50? Tell 192.168.123.1
15 111.247439 02:04:64:a4:39:d3 -> 02:04:64:a4:39:f2 ARP 60 192.168.123.50 is at 02:04:64:a4:39:d3
2092 5217.550877 02:04:64:a4:39:d3 -> 02:04:64:a4:39:f2 ARP 60 Who has 192.168.123.1? Tell 192.168.123.50
2093 5217.550911 02:04:64:a4:39:f2 -> 02:04:64:a4:39:d3 ARP 42 192.168.123.1 is at 02:04:64:a4:39:f2
</pre>
<p>Which would of course be insufficient to keep the DAT Cache fully up to date during the time a client is connected.</p> alfred - Feature #251 (New): batadv-vis: Add support for B.A.T.M.A.N. V throughputhttps://www.open-mesh.org/issues/2512016-05-14T07:54:27ZRussell Seniorrussell@personaltelco.net
<p>I'm experimenting with BATMAN_V on the lede-project revision reboot-231-gf8abb68 with batman-adv and alfred. The batadv-vis program reports:</p>
<p>root@mesh-test1:/# batadv-vis -v<br />batadv-vis 2016.1<br />VIS alfred client</p>
<p>With a three node test network, mesh-test1 and mesh-test2 are linked via both ethernet and wifi ibss mode, mesh-test3 is linked only with wifi, and I get odd looking results from batadv-vis:</p>
<p>root@mesh-test1:/# batadv-vis | grep -v TT<br />digraph {<br /> subgraph "cluster_00:0f:b5:97:28:9d" {<br /> "00:0f:b5:97:28:9d" <br /> "00:0f:b5:0c:e0:84" [peripheries=2]<br /> }<br /> "00:0f:b5:97:28:9d" -> "00:0f:b5:0e:71:5b" [label="2.550"]<br /> "00:0f:b5:0c:e0:84" -> "00:12:cf:83:7b:09" [label="6.711"]<br /> subgraph "cluster_00:0f:b5:0e:5d:8f" {<br /> "00:0f:b5:0e:5d:8f" <br /> "00:0f:b5:0e:71:5b" [peripheries=2]<br /> }<br /> "00:0f:b5:0e:5d:8f" -> "00:12:cf:83:7b:09" [label="6.711"]<br /> "00:0f:b5:0e:71:5b" -> "00:0f:b5:97:28:9d" [label="2.550"]<br />}</p>
<p>The numbers don't seem to ever change, and are way higher than what I would expect from ETX. I'm informed, not surprisingly, that BATMAN_V doesn't use ETX. Whatever metric is used, it might be nice to have it reported.</p> batman-adv - Feature #206 (New): Distributed IPv6-NDP cache to reduce overhead https://www.open-mesh.org/issues/2062015-03-12T15:46:18ZRuben Kelevracyrond@gmail.com
<p>Currently the Neighbor Discovery Protocol does takes much air-time and idle-bandwidth because of the broadcasts which are send thru the network.</p>
<p>It would be nice if the querys could be stored on the nodes, distributed, to use some of ram of the nodes usefully and reduce network overhead.</p>
<p>One possible solution would be:</p>
<ul>
<li>If an IPv6 is queryed by the local client, the node make three hashes and match them to the nearest mac-address of other nodes, and query them.</li>
<li>* If they all send NX do send the query as normal broadcast.</li>
<li>* * If the broadcast get an answer, send an update to the three nodes.</li>
<li>* If they does not return any answers for more than 20 seconds, do a normal broadcast. (redo querys for each Neighbor-Discovery-Query the node get)</li>
<li>If a node get no query for 2h, delete the entry.</li>
<li>If a node get more than $StoreLimit entrys, delete the oldest one.</li>
</ul> batmand - Feature #4 (In Progress): Request: Support iproute2https://www.open-mesh.org/issues/42007-01-21T11:44:47ZAnonymous
<p>Current used version: B.A.T.M.A.N.-III v0.1.1 beta (compability version 2)</p>
<p>I'd like to use batmand without obsolete ip-aliasing.</p>
<p>Example:<br />ip addr add 10.191.1.44/16 brd 10.191.255.255 dev tap0</p>
<p>Suggested Option:<br />batmand tap0 10.191.1.44</p>