gluon-respondd: no updates after first contact

[blocktrron]

At FFDA, we are experiencing our nodes on current Gluon master not sending respondd messages to our map backend. Nodes will send one message and won't answer on any other request.

They appear to be offline on map while the status-page is still reachable and mesh links are also drawn.

Last known working commit currently is f7f659c2541011fb406243abbaaa16f0baedba74.

[rotanid]

7351fb5d4a58c685dafeda9545145177ffe75969 should be the last working, as the only firewall related changes were after that with https://github.com/freifunk-gluon/gluon/pull/1124 by @christf

[rotanid]

so @mweinelt reported he didn't have issues anymore after a reboot? does this work for every affected node?

[christf]

let's investigate if this indeed is the firewall and what we can do about it. Can you please check the console log whether you can see rejected packets that correlate with the requests being sent?
Also: Can you please confirm that 7351fb5 is working?

[mweinelt]

@rotanid it works for a while after boot and fails to work after that. When I started tcpdump on the interface it starts working again, presumably due br-client entering promiscuous mode.

@christf not sure what you mean … but my device uses the plain (legacy) mesh on the wan port, and the batman-adv neighbourship looks fine.

[christf]

@mweinelt you could try tcpdump -p to not start promisc mode.

I wondered if you see any droped packets in the dmesg-ring-buffer. you could increase verbosity by setting log = 1 for the respective zone.

completing the picture, we have the following information:
02:41 rotanid| würde heißen in der liste fehlt was?
02:41 rotanid| https://github.com/freifunk-gluon/gluon/pull/1124/files#diff-e6cbbcd8a68c9a146e6ff5649b05654dR42
02:44 hexa-| 'router-solicitation', 'neighbour-solicitation', 'router-advertisement', 'neighbour-advertisement',
02:44 hexa-| sieht okayish aus
02:45 hexa-| fd01:67c:2ed8:6100:ea94:f6ff:fe69:4d86 dev ffda-br FAILED
02:45 hexa-| auf dem gateway

this points to issues with NDP.

@mweinelt You are seeing this on a device having MOW enabled, correct? If so, are you also seeing this on devices without MOW/MOL?

[mweinelt]

@christf I think we can rule out MOW/MOL, because all of our 20 experimental routers are affected.

I think you broke MLD and that is why NDP is not working.

REJECT(src mesh)IN=br-client OUT= MAC=33:33:00:00:00:01:e8:94:f6:69:4d:86:86:dd SRC=fe80:0000:0000:0000:ea94:f6ff:fe69:4d86 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=72 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=130 CODE=0 
REJECT(src mesh)IN=br-client OUT= MAC=01:00:5e:00:00:01:e8:94:f6:69:4d:86:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 

Dropping IPv4 Multicast (All Nodes) probably isn't an issue.

[mweinelt]

We're gonna inform our users when the new firmware is ready with the following snippet to update during the console, which is still reachable as a local client or from WAN.

ip6tables -I zone_mesh_input 1 -p ipv6-icmp -m icmp6 --icmpv6-type 130/0 -j ACCEPT
autoupdater

[NeoRaider]

Should be working now.

[mweinelt]

Confirmed working.