RT-AX88U "ISP's DHCP does not function properly" but manual udhcpc call works

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.


Occasional Visitor
This morning, I started having significant network issues. I have Cox internet, a Arris cable modem (not router/NAT), and that's it. The router started showing that the ISP's DHCP is not functioning properly. The router's syslog is similarly vague.

I connected a Raspberry Pi directly to the modem, turned on a packet capture (tcpdump), left DHCP on, and turned the modem on so I'd get a capture of the entire boot sequence of the router and DHCP traffic. The RPi was successfully able to get an IP address, and Wireshark analysis of the dump shows that the DHCP looks fine, but the DHCPv6 has an invalid message-type in the "Confirm XID" message (Apparently the client asked for a fully-qualified-domain-name, and something replied with a null response, but "Only the following message types are permitted to use OPTION_CLIENT_FQDN: SOLICIT, REQUEST, RENEW, REBIND, ADVERTISE, and REPLY"). However, the rest of the DHCPv6 messages look right.

When I SSH directly into the router, I can see that udhcpc is running (via ps) but not doing anything particularly useful. If I kill it then run the same command shown in ps, it doesn't work, but if I modify it a variant of it, I get this output:

[email protected]:/tmp/home/root# /sbin/udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -t30 -T3 -A160 -O33 -O249 -v
udhcpc (v1.24.1) started
eth0: No such process
Sending discover...
Sending select for
Lease of obtained, lease time 30
result: OK
2.248set ibw into 10Gbps due to unlimited
set ibw obw into 10Gbps due to unlimited
Error: Cannot run ioctl w/ req 0xC040BF06 with arg 0xff89ce60 Operation not permitted
Push forward IQoS policy size[494] result: NG

You can see the temporary address, and this command takes roughly 30 seconds to run, but at the end of it 'ip address' shows that I then had a valid, external IP address and my internet suddenly works.

I have no idea what's going on. Cox is sending a bad DHCPv6 message, but the rest of it looks right (though there does seem to be some "extra" DHCP traffic the modem is letting through, which is weird, but has different transaction IDs from what the router is using). Even if I disable IPv6 in the Asus router config it continues to fail. Then there's that other error udhcpc printed, but that similarly doesn't make sense.

So is it seeing that DHCPv6 thing early and giving up? Or is there something else going on? The Asus backend is not verbose about what is triggering the "does not function properly" message.

I have about a day on this DHCP lease before I have to do this again, and I have a Cox tech coming out (which will be totally worthless, except that I'll get to show him Wireshark saying "your server is doing bad stuff").

Regardless, I need this fixed. I would appreciate any help anybody can offer!

Some additional notes:

- I had a *slightly* outdated firmware, but while debugging this I updated it to the latest firmware; this did not fix the issue.
Last edited:


Occasional Visitor
I'm attaching the pcap file, though I had to rename it to .txt. It is obviously not a text file.


  • ModemStartup.txt
    74.8 KB · Views: 21


Senior Member
Sorry if this is not directly helpful but for what it's worth I think the WAN DHCP lease handling is broken. I found out on my RT-AX86u that if I unplug the WAN cable and put it back in there is nothing that forces udhcpc to release/renew. So I wrote my own script to monitor eth0 and do the same using the appropriate kill commands. In my case that meant loss of internet connectivity every 48 hours because my Huawei modem / ISP drops connection for about 2 seconds. So even though router saw eth0 go down and come back up it did nothing.

Here is the script I wrote (I'm sure this shouldn't have been necessary):



ip monitor link dev eth0 | while read event; do

        logger "maintain-wan-lease detected eth0 event: "$event

        case $event in

        *'NO-CARRIER'* )
                if [ $renew_wan_lease -eq 0 ]; then
                        logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
                        killall -SIGUSR2 udhcpc

        *'LOWER_UP'* )
                if [ $renew_wan_lease -eq 1 ]; then
                        logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
                        killall -SIGUSR1 udhcpc

Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!