IPv6 works on clients with default config, not with "default config"

New user on a DIR-882 and very happy so far. Been debugging an issue I've been having over the last few days and finally found a solution after reinstalling and tracking every change. However I still don't understand it or how to find the root cause. So in addition to maybe helping someone with the same issue, anyone want to help me figure out what is going on?

From a clean install, IPv6 works fine. My ISP assigns me a /56 that is delegated in /64 chunks to connected clients. I have a Windows machine, a MacOS laptop, a FreeBSD server and a Linux media player. They all receive IPv6 addresses and routes, can ping Google over IPv6 and score 10/10 on test-ipv6.com.

However, when I change the IP addresses of the LAN via LuCI ( -> IPv6 stops working (IPv4 still fine). None of the machines get IPv6 addresses other than their own link-local ones, the Windows machine doesn't get an IPv6 address via DHCP and manual router solicitation messages from the Linux client go unanswered (I can see them arriving on br-lan via tcpdump but there is no reply). I can still ping from the router however.

When I change the IP address via LuCI (or if I click edit and save without changing anything), it wants to apply the following (previously unset) settings, which I've managed to confirm cause the issue:

uci set dhcp.lan.ra_maxinterval='600'
uci set dhcp.lan.ra_mininterval='200'
uci set dhcp.lan.ra_lifetime='1800'
uci set dhcp.lan.ra_mtu='0'
uci set dhcp.lan.ra_hoplimit='0'
uci set dhcp.lan.ra_management='1'

From what I can tell from the wiki, these are the default settings. I've been trying to find out where these changes apply but see no diff in /etc/dnsmasq.conf or /etc/odhcp6c.*. There must be a change somewhere though, as applying these settings makes IPv6 stop working for clients and removing them from /etc/config/dhcp and rebooting makes IPv6 work again. However I'm not sure where else to look.

Using latest snapshot (r16575-4dcdc8249c) but saw same behaviour with 2 other builds from last week.

Ok very interesting you are ipv6 of base but not when you change the ip of lan it's right

I'm on openWRT behind livebox isp orange France but not ipv6 for the moment because delegation prefixe is not avalaible..

1 Like

The changed behaviour is due to to recent changes by @systemcrash
The PR added help texts, and also provided some new detailed config fields for odhcpd.

I noticed the added config items to config, but didn't notice (yet) problems with IPv6.

It is related to odhcpd (not odhcp6c).

Reference to

and the discussion thread (last few messages)

I might change the currect "default" setting values in those fields defined in the PR to "placeholder", so that the values are not unintentionally placed there.

1 Like

Got it, thanks! I will have a look.

I couldn't find any config files in /etc related to odhcpd (non-6c) but I see now that it loads /lib/netifd/dhcpv6.script and has some environment variables. I'll see if I can find changes in either of those.

The added config seems fine to me since they are just the default settings. It's just that something changes even with the explicit default config but I haven't yet been able to figure out what.

i have that, :frowning:

config dhcp 'lan'
        option interface 'lan'
        option dhcpv4 'server'
        option start '130'
        option limit '100'
        option leasetime '12h'

config dhcp 'lan6'
        option interface 'lan'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option start '100'
        option limit '150'
        option leasetime '12h'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config dhcp 'wan6'
        option interface 'wan6'
        option ignore '1'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master 1

But are they really? Wiki says so, but at least I did not verify them from sources before I merged the PR from @systemcrash

@systemcrash , did you look into the details of the assumed defaults when you set them in the PR?

Looking at the actual odhcpd sources, some of them are really defaults (ra_maxinterval 600), some of them are normally calculated from other values (600/3=200), and some seem to differ at the first glance (ra_lifetime -1 != 1800), and some are unsset by default (hoplimit).


The strange part is that eventhoug they are marked optional, they get set in any case into uci config file.

Like I said above, I will likely changed them to "placeholder" instead of "default", so that they would not be set, but the defaults would be visible.

I think the problem is in use a default value instead of placeholder since i think the default value is taken as a value set by the user. Optional just tells that the value can be omitted but doesn't skip the value if it's equal to the default one. (in theory)

1 Like

I pushed a fix to master with

I also backported the fix to 21.02 (where I had already backported the original faulty commit), but sadly the old code will get into 21.02.0-rc1 that is currently being compiled.

1 Like

Yeah - I dug into the C code and followed the defaults (compared with the wiki). I was not sure about "placeholder" so I went with default (didn't cause problems on my device).

Thanks for the quick fix! :pray:

I wonder whether you could test by tweaking the setting

uci set dhcp.lan.ra_hoplimit='0'

to e.g. 10 or so.

Possibly also

uci set dhcp.lan.ra_mtu='0'

Those settings get auto changed according to the source code anyway. Worth checking whether they are the culprit (in your case).

1 Like

Got it! ra_hoplimit=0 is fine, but ra_mtu=0 causes the issue. Same issue with 10, but according to the UI the minimum value is supposed to be 1280. With ra_mtu=1280 everything works as before.

Looking at config.h linked above I can't find a default value for ra_mtu, but it appears from line 780 forwards that setting it below 1280 causes an error.


The current help text below the MTU field is The MTU to be published in RA messages. Default is 0 (0 ). Min 1280.. I would suggest removing "default is 0" since that appears to not be the case. Possibly also adding that the max is 65535.


I guess the code doesn't work exactly as I thought. My interpretation was that if a zero value was encountered, it looks at the general interface config. That seems to be where the trip-up was happening. Less than 1280 gets set to 1280 anyway.

	if (mtu == 0)
		mtu = odhcpd_get_interface_config(iface->ifname, "mtu");

	if (mtu < 1280)
		mtu = 1280;

The wiki says 0 is default which should do as described above, so it seems a problem lies elsewhere that needs taking care of.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.