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.
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)
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.