Open Mesh: Issueshttps://www.open-mesh.org/https://www.open-mesh.org/favicon.ico?16699090422019-07-13T11:06:24ZOpen Mesh
Redmine batman-adv - Bug #396 (Rejected): Memory leak in batadv_tt_global_addhttps://www.open-mesh.org/issues/3962019-07-13T11:06:24ZMartin Weineltmartin@darmstadt.freifunk.net
<p>Hi,</p>
<p>on 5.2.0-rc7+ with batman-adv v2019.2-1-gc92331e0 I'm occasionally seeing<br />the following with kmemleak:</p>
<pre>
unreferenced object 0xffff8b1557cc9480 (size 128):
comm "softirq", pid 0, jiffies 4298398929 (age 22408.132s)
hex dump (first 32 bytes):
f4 f2 6d 85 c1 7c 00 80 00 00 00 00 00 00 00 00 ..m..|..........
d0 8b ec 55 15 8b ff ff 00 00 00 00 00 00 00 00 ...U............
backtrace:
[<000000006e2c9ed6>] batadv_tt_global_add+0x5fa/0x630 [batman_adv]
unreferenced object 0xffff8b1559c9fa80 (size 64):
comm "softirq", pid 0, jiffies 4298398929 (age 22408.132s)
hex dump (first 32 bytes):
00 16 4a 3a 15 8b ff ff 00 00 00 00 00 00 00 00 ..J:............
00 00 00 00 00 00 00 00 c0 94 cc 57 15 8b ff ff ...........W....
backtrace:
[<000000002053c4bb>] batadv_tt_global_add+0x53c/0x630 [batman_adv]
</pre>
<p>I've looked up the function offsets:</p>
<pre>
batadv_tt_global_add+0x5fa/0x630:
batadv_tt_global_add at /var/lib/dkms/batman-adv/v2019.2-1-gc92331e0/build/net/batman-adv/translation-table.c:1711
batadv_tt_global_add+0x53c/0x630:
batadv_tt_global_orig_entry_add at /var/lib/dkms/batman-adv/v2019.2-1-gc92331e0/build/net/batman-adv/translation-table.c:1637
(inlined by) batadv_tt_global_add at /var/lib/dkms/batman-adv/v2019.2-1-gc92331e0/build/net/batman-adv/translation-table.c:1801
</pre> batctl - Bug #367 (Rejected): Show TQ in batctl neighborshttps://www.open-mesh.org/issues/3672018-11-29T00:27:01ZMartin Weineltmartin@darmstadt.freifunk.net
<p>Currently batctl neighbors shows interface, mac and last-seen. It would be helpful if I could see the TQ towards the neighbor as well. This would reduce the need to grep the originators list for the chosen path.</p> batman-adv - Bug #327 (Closed): Possible Fragmentation Issuehttps://www.open-mesh.org/issues/3272017-03-03T02:01:41ZMartin Weineltmartin@darmstadt.freifunk.net
<p>HTTP download of a small file from the webserver stalls, while large file works flawlessly.</p>
<p>Setup is as follows:</p>
<ul>
<li>Embedded Router, Gluon, batman-adv 2016.5</li>
</ul>
<blockquote>
<p>connected to Gateway via Ethernet (1500 MTU), speaking BATMAN IV</p>
</blockquote>
<ul>
<li>Gatway, batman-adv 2017.0</li>
</ul>
<blockquote>
<p>connected to Webserver via Ethernet (1500 MTU), reachable via Routing</p>
</blockquote>
<ul>
<li>Webserver</li>
</ul>
<blockquote>
<p>ships Firmware manifests and updates</p>
</blockquote>
<p>Since upgrading to batman-adv 2017.0 on the gateway our autoupdater is unable to download its update manifest, a downgrade to 2016.5 resolved this.</p>
<p>I've attached pcaps of the upper (bat0) and lower (bat0 slave interface) interfaces of both router and gateway, as well as the file that fails to download.</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> 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>