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

[iadjunct]

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:

admin@RT-AX88U-6808:/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 192.168.100.10...
Lease of 192.168.100.10 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 192.168.100.10 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.

 

[iadjunct]

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

 

[Lynx]

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

#!/bin/bash

renew_wan_lease=0

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
                        renew_wan_lease=1
                fi
        ;;

        *'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
                        renew_wan_lease=0
                fi
        ;;
        esac

done

 

[optimalo]

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

#!/bin/bash

renew_wan_lease=0

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
                        renew_wan_lease=1
                fi
        ;;

        *'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
                        renew_wan_lease=0
                fi
        ;;
        esac

done

Just replying to confirm, that this script is working and solved my issue with my Asus RT-AX68U showing a red light everytime my mobile network providers WAN IP lease would get renewed!
I am using a Huawei B818-263 LTE router and was running into this issue every few days. If anybody wants to use this script, you need to switch your Asus router to the Merlin firmware. Enable user scripts and the JFFS partition in the system settings. Use winscp to save Lynx's script to the jffs partition under the scripts folder. Use a SSH terminal (I used Putty) to clean the scripts formatting for Unix use if you used Winwows (it's one command) and set some file rights with another command.

You can find all info here: https://www.snbforums.com/threads/asuswrt-merlin-and-nextdns-issue.58282/page-2#post-529694


Thank you so much Lynx, this issue has been a pain in the butt. This behaviour should really be fixed by Asus! :-(

 

[Lynx]

Glad to hear it. Another user just messaged me to confirm the same.

Here is the script on GitHub:

maintain-wan-lease/README.md at master · lynxthecat/maintain-wan-lease

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

Yes I agree, Asus should implement something along these lines because the default behaviour is broken.

Please keep me posted in terms of whether this solves the problem for you as well. Like I said, I could simulate by just unplugging eth0, then plugging it back in to verify script properly releases and renews. But the real test is when the modem drops eth0 and puts it back up, to see that the release and renew results in maintaining internet connectivity.