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 (192.168.1.1 -> 10.0.1.1) 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.
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.
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.
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.
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).
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)
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.
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).
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.
edit
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.