Gluon: respondd: No reply when receiving for ff05::2:1001 from yanic server

[charlemagnelasse]

Gluon 2019.1 is only listening for ff05::2:1001 on br-client. But something is dropping these UDP packets (ebtables-filter-multicast?). When I have tried the yanic workaround from https://github.com/FreifunkBremen/yanic/issues/167 (to at least send all requests to a single domain), it was submitted to the devices but none of them responded.

I have also checked whether the same globally routable IPv6 source and routable multicast IPv6 destination pair works when using ICMPv6. Either an iptables/ip6tables/ebtables rule prevented the receiving of it or respondd is ignoring ff05::2:1001 receiving on br-client. At least the br-client is the device in the same subnet as the source IPv6 address.

[mweinelt]

Can you confirm, using tcpdump, that requests arrive on br-client?

[charlemagnelasse]

Yes, both ICMPv6 and UDP had the same global routable IPv6 address. But only the ICMPv6 got an response

[mweinelt]

Can you post the output of a few minutes of running the following, please?

tcpdump -ni br-client port 1001

[charlemagnelasse]

When I use this ugly "send the ff05::2:1001 for all domains to a single interface hack" (which would not work in practices as you can see in https://github.com/FreifunkBremen/yanic/issues/167) on the yanic server, I see during a 3-4 minutes run:

19:29:30.015086 IP6 2a03:2260:2020:2::1.39316 > ff05::2:1001.1001: UDP, length 34
19:29:30.015293 IP6 2a03:2260:2020:4::1.36302 > ff05::2:1001.1001: UDP, length 34
19:29:30.025749 IP6 2a03:2260:2020:3::1.43729 > ff05::2:1001.1001: UDP, length 34
19:29:30.025987 IP6 2a03:2260:2020:1::1.48081 > ff05::2:1001.1001: UDP, length 34
19:29:30.026117 IP6 2a03:2260:2020:5::1.45634 > ff05::2:1001.1001: UDP, length 34
19:29:30.026368 IP6 2a03:2260:2020:0::1.43338 > ff05::2:1001.1001: UDP, length 34
19:30:30.015015 IP6 2a03:2260:2020:2::1.39316 > ff05::2:1001.1001: UDP, length 34
19:30:30.015228 IP6 2a03:2260:2020:4::1.36302 > ff05::2:1001.1001: UDP, length 34
19:30:30.025708 IP6 2a03:2260:2020:3::1.43729 > ff05::2:1001.1001: UDP, length 34
19:30:30.025934 IP6 2a03:2260:2020:1::1.48081 > ff05::2:1001.1001: UDP, length 34
19:30:30.026102 IP6 2a03:2260:2020:5::1.45634 > ff05::2:1001.1001: UDP, length 34
19:30:30.026308 IP6 2a03:2260:2020:0::1.43338 > ff05::2:1001.1001: UDP, length 34
19:31:30.028721 IP6 2a03:2260:2020:2::1.39316 > ff05::2:1001.1001: UDP, length 34
19:31:30.029023 IP6 2a03:2260:2020:4::1.36302 > ff05::2:1001.1001: UDP, length 34
19:31:30.029149 IP6 2a03:2260:2020:3::1.43729 > ff05::2:1001.1001: UDP, length 34
19:31:30.029385 IP6 2a03:2260:2020:1::1.48081 > ff05::2:1001.1001: UDP, length 34
19:31:30.029501 IP6 2a03:2260:2020:5::1.45634 > ff05::2:1001.1001: UDP, length 34
19:31:30.029729 IP6 2a03:2260:2020:0::1.43338 > ff05::2:1001.1001: UDP, length 34

Also the return path:

$ ip route get 2a03:2260:2020:1::1
2a03:2260:2020:1::1 from :: dev br-client  src 2a03:2260:2020:1:e039:8dff:fec9:0baa  metric 256

[charlemagnelasse]

An ICMP echo request/reply looks like this:

19:53:21.767396 IP6 2a03:2260:2020:1::1 > ff05::2:1001: ICMP6, echo request, seq 20, length 64
19:53:21.767438 IP6 2a03:2260:2020:1:e039:8dff:fec9:0baa > 2a03:2260:2020:1::1: ICMP6, echo reply, seq 20, length 64

[charlemagnelasse]

Respondd it also running:

 3330 root     38384 S    /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh-vpn -i vx_mesh_wan -g ff05::2:1001 -i br-client -t 10

And it also works fine when I stop respondd and start it with

/usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh-vpn -i br-client -t 10 -g ff05::2:1001 -i br-client -t 10

And change the yanic server to use ff02::2:1001 again. But the yanic server is then not using the globally routable address as source but the link local address.

[mweinelt]

Can we get a link to your site? Also are there custom packages installed?

[charlemagnelasse]

I think it works for you because you are using link local addresses for the request from yanic and not globally routable. See your answer at https://forum.freifunk.net/t/gluon-2019-1-x-knoten-erscheinen-nicht-in-der-map-respondd/21164/33 and compare the source address.

[NeoRaider]

A non-link-local multicast group should be used with a global address, this is fine. Pings to the multicast group are working, so this proves that this is working as expected.

Issues might exist either in respondd itself, or in Gluon's firewall setup. Please provide a link to your site config, as well as the output of ip6tables -nvL.

[NeoRaider]

No reply, closing. Please reopen if the issue persists.