Gluon: /etc/init.d/gluon-respondd ignores br-client unless dhcpv6 is successful

[yanosz]

Version: 2018.2.2
Device TP-Link 3600

Is:

• When dhcpv6 has not yet succeeded for br-client, respondd is not bound to br-client

Should:

• respondd should bind to br-client if it is there

Cause:

Before binding /etc/init.d/gluon-respondd queries for usable client interfaces using

local clientdevs=$(for dev in $(echo "$ifdump" | jsonfilter -e "@.interface[@.interface='$(cat /lib/gluon/respondd/client.dev 2>/dev/null)' && @.up=true].device"); do echo " -i $dev -t $MAXDELAY";done;)`

Testing the query manually boils down to:

echo "$(ubus call network.interface dump)" | jsonfilter -e "@.interface[@.interface='$(cat /lib/gluon/respondd/client.dev 2>/dev/null)' && @.up=true].device"

As of 2018.2.2 br-client is configured as

config interface 'client'
        option igmp_snooping '1'
        option type 'bridge'
        option auto '1'
        option ra_holdoff '30'
        option multicast_querier '1'
        option macaddr '64:66:b3:4f:fc:ac'
        list ifname 'local-port'
        list ifname 'bat0'
        option ipv6 '1'
        option keep_ra_dnslifetime '1'
        option sourcefilter '0'
        option peerdns '1'
        option robustness '9'
        option reqprefix 'no'
        option query_interval '2000'
        option query_response_interval '500'
        option proto 'dhcpv6'

This configuration causes ubus call network.interface dump to consider as down until dhcpv6 has suceeded - but due to option auto '1' the interface is up anyway.

Impact:

• If no configuration IPv6 mechanism is present, respondd will never bind to br-client (that happened to me)
• If dhcp6 is slow (e.g. radvd intervals) respondd takes a respawn interval to bind to br-client, i.e. slow start.
• If the network is unstable (i.e. mesh) respondd might discard the interface temporarily.
• So far, multicast traffic appears to be concencerned, only. I guess, that yanic's unicast ping for unreachable nodes might compensate the impact for a while.

Remarks:

• It feels strange to query for br-client and exclude it (possibly). I'm not aware of any configurations requiring explicit client devices scanning.

[NeoRaider]

Without RA or DHCPv6, br-client has no non-link-local IP address; while in Gluon v2018.2.x, there is also the option to use the link-local multicast group (ff02::...) for respondd, this possibility doesn't exist in the master anymore, and a non-local (ULA / global) address should be used (it might be possible to use the ff05::... multicast group with a link-local unicast address, but it's not recommended). So without the node getting a proper address, respondd will not work anyways.

Does your image include gluon-radvd? This should always provide an address to your node - although I'm not sure how it interacts with DHCPv6... I think it should work fine as long as it is run in unmanaged (stateless) address autoconfig mode.

[yanosz]

nope - gluon-radvd is not present. I use ff02:: for multicast.

[yanosz]

Adding gluon-radvd causes the br-client to be considered as up. works - thanks :)

I'm sill undecided what to do with /etc/init.d/gluon-respondd for cases like this.

• It could log write log messages, joining a site local mc group is not possible
• It could simply use br-client without using ubus
• && @.up=true could be removed to avoid excluding br-client

I guess, that additional logging would have saved me some time, here.

[Adorfer]

for my understanding: This "dhcpv6 successfull" really referrs to dhcpv6?
in other words: slaac (like radvd prefix announces) are NOT sufficient to get respondd working on br-client?

Ind this case it should really be documented, since most community setups i have seen so far do not use DHCPv6 at all, just slaac.

[belzebub40k]

@Adorfer we (Freifunk MWU) don't have dhcpv6 just radvd and the respondd on the nodes running v2018.2.2 look fine.

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

[NeoRaider]

@Adorfer SLAAC is sufficient. The only way it could be insufficient is when you are using DHCPv6 in managed mode, so a node doesn't get an address until DHCPv6 is finished. Such setups are unsupported by Gluon (either run without DHCPv6, or in unmanaged mode).

[NeoRaider]

Adding gluon-radvd causes the br-client to be considered as up. works - thanks :)

I'm sill undecided what to do with /etc/init.d/gluon-respondd for cases like this.

* It could log write log messages, joining a site local mc group is not possible

* It could simply use br-client without using ubus

* `&& @.up=true` could be removed to avoid excluding br-client

In Gluon master, this doesn't really make sense: The ff02::... group is not joined anymore on br-client, so you need a non-local address on br-client. As soon as you get a non-local address, the interface is considered up anyways, so everything is working as expected.

I guess we could make gluon-radvd a default feature to avoid such problems - the only reason you might not want to include it would be when you are running DHCPv6 in managed mode, but in that case you're on your own anyways...

[yanosz]

you need a non-local address on br-client. As soon as you get a non-local address, the interface is considered up anyways, so everything is working as expected.

I guess we could make gluon-radvd a default feature to avoid such problems - the only reason you might not want to include it would be when you are running DHCPv6 in managed mode, but in that case you're on your own anyways...

Sounds cool, thanks.
IMHO regarding master with no gluon-radvd present : It may take some time for the interface to receive a ra and respondd to restart. When debugging in the meantime, people may wonder why respondd doesn't listen on br-client. Making gluon-radvd default or add additional logging will help.