386.5_2 IPv6 DHCP-PD Broken

[myjdrz69]

Since the latest firmware update for my ASUS RT-AX3000 router (RT-AX58U firmware), the IPv6 DHCP-PD is not kicking in. I find I have to disable it manually and enable it. If I reboot the router, I have to disable and manually enable it to get the functionality to return. Is anyone else seeing this with the latest 386.5_2 firmware? I have tried uploading the firmware again, initialing (factory defaults) with no change. Seems something is broken now with IPv6. I wonder if this is related to v6plus fix that ASUS put in the latest Jan firmware for the RT-AX3000.

 

[Frank Monroe]

Since the latest firmware update for my ASUS RT-AX3000 router (RT-AX58U firmware), the IPv6 DHCP-PD is not kicking in. I find I have to disable it manually and enable it. If I reboot the router, I have to disable and manually enable it to get the functionality to return. Is anyone else seeing this with the latest 386.5_2 firmware? I have tried uploading the firmware again, initialing (factory defaults) with no change. Seems something is broken now with IPv6. I wonder if this is related to v6plus fix that ASUS put in the latest Jan firmware for the RT-AX3000.

I am having a similar issue. I am using sing IPv6 in passthrough mode. After several days, clients lose their IPv6 information, (DNS, IP address...etc) and thus revert back to IPv4. I have to reboot the router to fix the issue. If I revert back to 386.3_2, the problem goes away. I first noticed the issue with version 386.4. I am using an RT-AC5300.

 

[Zekamashi]

Did you ever find a fix for this issue? RT-AC68U has the same problem.

Settings:
ISP - XFINITY (Comcast residential)
Connection type - Native
DHCP-PD - Enabled
Release prefix on exit - Enabled
LAN Prefix Length - 64
Auto Configuration Setting - Stateless
DNS servers - 2606:4700:4700::1111, 2001:4860:4860::8888
Enable Router Advertisement - Enable

 

[bengalih]

So I have an RT-AC68U and I'm still on 386_3.2 and haven't been experiencing any issues. I was going to upgrade prior to viewing this thread, but am holding off until we have some type of resolution or know a bit more about it.

This is what I can tell you based on what I know - hopefully it will assist you all in your troubleshooting so you can gather some more information.
If we are lucky maybe @RMerlin can chime in and let us know if he has any insight.

A quick note on my setup: It is a little unique as I am using my RT-AC68U to bypass my AT&T Fiber Modem (running wpa_supplicant to provide 802.11x auth of AT&T's certificates). I'm also running in Static IPv6 mode due to an issue using Native with how AT&T hands out subnets. When I run in Native mode my router is given an address on a network that is not routable outside of AT&T, and another network which it hands out to clients which can be routed. This prevents me from reaching my router directly over IPv6 over the internet, so my static configuration allows me to force the proper network. However, because AT&T expects their clients to request DHCP addresses, I still have to run a manual odhcp6c process on the router to request (at minimal the Prefix) from AT&T in order for the routes to be established.

Anyway - most of the above probably isn't relevant in many ways, but wanted to lay it out there. You can, for the most part, assume I'm just using a Static IPv6 configuration with RA enabled. This appears to work properly as I see the RA in my packet captures and my clients are properly getting their prefixes for their IPv6 addressing.

From what I can gather this is how RA is configured and works on the current firmware versions:

1) When you toggle RA on or off in the IPv6 settings it configures an NVRAM variable:

ipv6_radvd=1
ipv6_radvd=0

2) Dnsmasq is responsible for handling router advertisements. When dnsmasq is started it checks for the existence of the above nvram variable. If it is set to enabled it adds some additional lines to the dnsmasq.conf to enable advertisements. On my system, the lines added are:

ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-authoritative

These settings do the following:
- Enable Router Advertisements (enable-ra)
- Set the advertisements to go out over br0 every 10 seconds and have a lifetime of 600 seconds (ra-param)
- Suppress logging of standard info for RAs (quiet-ra)
- Sets the RA for the lan segment (br0) to be stateless (PD only) with a prefix length of 64 and a lease time of 600 seconds (dhcp-range)
- Sets dnsmaq as the authoritative DHCP server on configured network ranges (dhcp-authoritative).

To test enabling and disabling RA on your network you can, in its most basic form do this:

nvram set ipv6_radvd=1
service restart_dnsmasq

nvram set ipv6_radvd=0
service restart_dnsmasq

The above will set the appropriate option and the restart of dnsmasq will add and enforce the new configuration. If you are doing a packet capture on a client you will immediately see the RA packets start or stop.

Hopefully the above is enough to help you troubleshoot the issue and perhaps get a workaround in place. At the very least, I am hoping that when your RA fail that a simple restart of dnsmasq is enough to get them going again. In this way, you can maybe create a cron/cru job to restart on a regular basis.

When they do fail, you should look to the settings above to see somehow if the values have changed. If not, I suspect that dnsmasq itself is having an issue.

Other things to look at/try:

Perhaps making a user script to override these dnsmasq.conf settings:
- Remove "quiet-ra" and look at the logs generated when RAs are issued and compare it to when they are not.
- Maybe set the lifetime to longer than 5 minutes (I believe normal lifetimes are much greater 3600?). This might help existing clients continue to use the route for longer and may tolerate interruption of the issue longer. This will likely not help with new clients coming onto the network who haven't yet received an RA.

These are just some idea. As I don't have the issue I can't move further than this, but I am interested in the outcome as I don't want to upgrade if these are known issues.

good luck - and keep us posted!

 

[Frank Monroe]

I'm running in passthrough mode which I believe uses 6relayd to intercept modify and pass along router announcements from the upstream router. I too have issues where the announcements stop every few days and clients lose their IPv6 addresses. If I reboot the ASUS, normal behavior returns for a while. If I revert Merlin back to version 386_3.2, the problem goes away.

 

[bengalih]

Well that is interesting in as much that @Zekamashi above stated that he is in Native mode, which I suspect would use dnsmasq as well.
The OP (@myjdrz69) doesn't state what mode he is running.

If indeed you are all having the same issue, this would mean that an issue would appear to exist with *both* dnsmasq and 6relayd not properly sending out RAs, which I find to be highly unlikely.

I think those of you you having this issue are going to need to do some more troubleshooting as I don't think anyone is just going to have an answer.

I think we should confirm that indeed RA packets are not being sent out by doing a network capture on your clients to see how often they receive RA under normal circumstances and then see if they stop.
Also looking at the dnsmasq and/or 6relayd process running normally and when a problem exhibits. For dnsmasq verifying the .conf file and for 6relayd looking at the arguments in the command line via ps.
Also any syslogging from either service that appears or not under normal/problem conditions.

Finally, if you are able to isolate the bare minimum that is needed to fix the situation when it occurs (short of a full reboot), that might help it narrow it down.