It was observed that nodes (2018.1) sometimes don't report the IPv6 addresses via respondd. The list is (as far as I can see) then always empty. I've taken a snapshot of /proc/net/if_inet6 from such a node:
2a032260200f040356e6fcfffec9669c 1a8 40 00 00 br-client
fe8000000000000094b5e9fffefe81e0 1be 40 20 80 client0
fe8000000000000094b5e9fffefe81e3 1a9 40 20 80 primary0
2a032260200f010356e6fcfffec9669c 1a8 40 00 00 br-client
fe8000000000000094b5e9fffefe81e1 1bd 40 20 80 mesh0
fe8000000000000094b5e9fffefe81e4 1bc 40 20 80 vx_mesh_lan
fd01fd5900001c0056e6fcfffec9669c 1a8 40 00 00 br-client
fe8000000000000094b5e9fffefe81e4 03 40 20 80 eth0
fe8000000000000056e6fcfffec9669c 1aa 40 20 80 bat0
fe8000000000000056e6fcfffec9669c 1a8 40 20 80 br-client
00000000000000000000000000000001 01 80 10 80 lo
fd01fd5900001c000000000000010001 1a7 80 00 a0 local-node
2a032260200f030356e6fcfffec9669c 1a8 40 00 00 br-client
fe80000000000000144195fffe40f7dc 1a7 40 20 80 local-node
fe8000000000000094b5e9fffefe81e7 0f 40 20 80 mesh-vpn
The problem here is now that the second column (ifindex) can have more than 2 characters. But the scanf format string is only expecting two. The interface name is then not parsed correctly.
The device seemed to have reconfigured the network interfaces rather often during the 2 weeks it was up. This was the reason why the ifindex of most interfaces were rather high:
root@RC-AndreasSchubert11-Base:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether ee:fc:4c:3c:07:c7 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 96:b5:e9:fe:81:e4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e4/64 scope link
valid_lft forever preferred_lft forever
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br-wan state DOWN qlen 1000
link/ether 54:e6:fc:c9:66:9d brd ff:ff:ff:ff:ff:ff
15: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1426 qdisc pfifo_fast master bat0 state UNKNOWN qlen 1000
link/ether 96:b5:e9:fe:81:e7 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e7/64 scope link
valid_lft forever preferred_lft forever
421: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 96:b5:e9:fe:81:e0 brd ff:ff:ff:ff:ff:ff
422: local-port@local-node: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
link/ether 54:e6:fc:c9:66:9c brd ff:ff:ff:ff:ff:ff
423: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
inet 10.204.64.1/20 brd 10.204.79.255 scope global local-node
valid_lft forever preferred_lft forever
inet6 fd01:fd59:0:1c00::1:1/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
valid_lft forever preferred_lft forever
424: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 54:e6:fc:c9:66:9c brd ff:ff:ff:ff:ff:ff
inet6 2a03:2260:200f:303:56e6:fcff:fec9:669c/64 scope global dynamic
valid_lft 86391sec preferred_lft 14391sec
inet6 2a03:2260:200f:403:56e6:fcff:fec9:669c/64 scope global dynamic
valid_lft 86391sec preferred_lft 14391sec
inet6 2a03:2260:200f:103:56e6:fcff:fec9:669c/64 scope global dynamic
valid_lft 86394sec preferred_lft 14394sec
inet6 fd01:fd59::1c00:56e6:fcff:fec9:669c/64 scope global dynamic
valid_lft 86383sec preferred_lft 14383sec
inet6 fe80::56e6:fcff:fec9:669c/64 scope link
valid_lft forever preferred_lft forever
425: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN qlen 1000
link/ether 96:b5:e9:fe:81:e3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e3/64 scope link
valid_lft forever preferred_lft forever
426: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UNKNOWN qlen 1000
link/ether 54:e6:fc:c9:66:9c brd ff:ff:ff:ff:ff:ff
inet6 fe80::56e6:fcff:fec9:669c/64 scope link
valid_lft forever preferred_lft forever
444: vx_mesh_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc noqueue master bat0 state UNKNOWN qlen 1000
link/ether 96:b5:e9:fe:81:e4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e4/64 scope link
valid_lft forever preferred_lft forever
445: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UP qlen 256
link/ether 96:b5:e9:fe:81:e1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e1/64 scope link
valid_lft forever preferred_lft forever
446: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 256
link/ether 96:b5:e9:fe:81:e0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::94b5:e9ff:fefe:81e0/64 scope link
valid_lft forever preferred_lft forever
A quick fix would be:
diff --git a/package/gluon-mesh-batman-adv/src/respondd.c b/package/gluon-mesh-batman-adv/src/respondd.c
index ca7ae968..b3e899e4 100644
--- a/package/gluon-mesh-batman-adv/src/respondd.c
+++ b/package/gluon-mesh-batman-adv/src/respondd.c
@@ -94,7 +94,7 @@ static struct json_object * get_addresses(void) {
if (sscanf(line,
"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8
"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8"%2"SCNx8
- " %*2x %*2x %*2x %2x %"STRINGIFY(IF_NAMESIZE)"s",
+ " %*8x %*2x %*2x %2x %"STRINGIFY(IF_NAMESIZE)"s",
&addr.s6_addr[0], &addr.s6_addr[1], &addr.s6_addr[2], &addr.s6_addr[3],
&addr.s6_addr[4], &addr.s6_addr[5], &addr.s6_addr[6], &addr.s6_addr[7],
&addr.s6_addr[8], &addr.s6_addr[9], &addr.s6_addr[10], &addr.s6_addr[11],
It was observed that nodes (2018.1) sometimes don't report the IPv6 addresses via respondd. The list is (as far as I can see) then always empty. I've taken a snapshot of /proc/net/if_inet6 from such a node:
The problem here is now that the second column (ifindex) can have more than 2 characters. But the scanf format string is only expecting two. The interface name is then not parsed correctly.
The device seemed to have reconfigured the network interfaces rather often during the 2 weeks it was up. This was the reason why the ifindex of most interfaces were rather high:
A quick fix would be: