What's new

Router trouble RT-AX88U

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ciprian.trofin

Occasional Visitor
My router is Asus RT-AX88U, firmware version 3004.388.6.

The 8 port switch is used as follows:
- port 1: desktop
- port 2: printer
- port 3: NAS
- port 4: powerline adapter
- port 5: Raspberry Pi running PiHole

DHCP is enabled on router. PiHole works only as DNS (DHCP disabled).

The router has WiFi hotspots on both 2.4 and 5GHz bands

The powerline network works as follows:
- one end is static, connected by Ethernet cable to router switch port 4
- the other end is WiFi enabled (2.4GHz only), serving a hotspot with the same SSID/credentials as the router. DHCP is disabled on this device. Devices connected to powerline hotspot get the IP from router.
The ideea for powerline is to extend 2.4GHz coverage.

FWIW, powerline ends connect each other @200Mbps.

The issue is the following: after working for a while (could be 3-4 days, could be a few hours after a reboot), the devices in range of powerline hotspot fail to get an IP address. The system log shows lots of consecutive DHCPDISCOVER / DHCPOFFER messages, not followed by DHCPREQUEST.

Code:
Mar  4 19:40:21 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:21 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:40:26 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:26 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:40:31 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:31 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:40:35 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:35 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:40:44 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:44 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:40:59 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:40:59 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:04 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:04 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:07 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:07 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:09 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:09 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:13 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:13 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:22 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:22 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:41:39 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:41:39 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx

Moving in router's hotspot range result in success:
Code:
Mar  4 19:42:11 dnsmasq-dhcp[1129]: DHCPDISCOVER(br0) 30:09:c0:xx:xx:xx
Mar  4 19:42:11 dnsmasq-dhcp[1129]: DHCPOFFER(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:42:11 dnsmasq-dhcp[1129]: DHCPREQUEST(br0) 192.168.76.10 30:09:c0:xx:xx:xx
Mar  4 19:42:11 dnsmasq-dhcp[1129]: DHCPACK(br0) 192.168.76.10 30:09:c0:xx:xx:xx

Resetting the powerline devices (power cycling) does not solve the problem. Rebooting the router does, but the problem shows again later.

I had the same problem with previous router, an N66U (using latest Merlin FW). I upgraded mostly because of additional LAN ports. I am aware of port 5-8 troubles, but I had none.

Any advice ?
 
The issues with Ports 5-8 are random and obscure. This may be another variation.

To test properly, replace the PLAs with a wire (to test with). I'm going to guess the issue is repeated.
 
That's assuming its not a combined PLA with WiFi, so may not be possible to temporarily use an ethernet cable - but is the first step I'd try.

It does sound like an old problem I had way back around 4 years ago on 384.something - same thing in the logs the clients didn't do the request after an offer. Upgrading version nor full factory resets solved it, anywhere from 2-3 day to 2 weeks and it would come back.

I think restarting the dnsmasq service every week in a cron job kept it at bay. I tried every new release (with factory resets) but it persisted until about 386.x then magically disappeared. Not much help, I know, sorry!
 
Power gremlins? When was the power supply last changed? Is it the OE or an aftermarket? This is pretty non-specific, works sometimes, sometimes not. I've had these types of odd failures that were fixed with a new PS, even when the current one still 'worked'.
 
Thank you for your kind advice.
I will investigate as much as I can, according your suggestions, however I lack some hardware... :(


To me, it looks like the client does not receive the DHCPOFFER message from router. Is there any way to investigate if the DHCPOFFER is sent to the correct interface?

To explain: the router is placed in a room, the WPA is in another (WPA - Wireless Power Adapter, check below)
To allow roaming, I setup the WPA hotspot the same as the router hotspot (if course, different channels). When I move between rooms with my phone, my phone connects to the strongest (signal) hotspot, sends a DHCPDISCOVER broadcast, the router responds with an DHCPOFFER... and that's all. If I'm not mistaken, the DHCPOFFER is unicast, it is sent only to the requesting device but this means different interfaces, according the hotspot:
1. if the hotspot is the router - the interface is wireless
2. if the hotspot is the WPA - the interface is a wired port on router


The powerline adapter consists of 2 units:
- TL-PA4010 (TpLink Power Adapter, basically a Layer 2 unit, connected by Cat5 to router and plugged in a power outlet)
- TL-WPA4220 (TpLink Wireless Power Adapter, it is the other end of TL-PA4010, it has assigned an IP address)
The powerline connection between adapters is stable (I cron ping the WPA unit every 10 minutes and there are no interruptions).
 
For a while, I had no issues. After previous post, I installed scMerlin scripts, to allow me to restart dnsmasq service.

Today it showed again: when in range of Wireless Power Adapter, my device (phone) does not get an IP address; when in range of router, it does.

I tried (without restarting the router):
- restart dnsmasq service on router (via scMerlin scripts) - no improvement
- restart wifi service on router (via scMerlin scripts) - no improvement
- power cycle the Wireless Power Adapter - no improvement
- power cycle the Power Adapter (the one connected to router) - no improvement
- change the router port where the Power Adapter is connected - IT WORKED!

I find interesting that power cycling the Power Adapter does not solve my issue, but changing the switch (router) port did.

I also looks like my hunch about the router sending the DHCPOFFER to the wrong interface is plausible.

I there any way to reset (in software) the association between MAC addreses of devices and router interfaces ?
 
So far, the only software solution I found working is rebooting the router in command line or cru.

Is it possible to reset (in software) only one port of the switch ?
 
The router is working stable - 3 weeks so far. One caveat - the router is power cycled each week using a "digital timer" power outlet. The outlet cuts the power monday morning and restores it after 5 minutes. So far, it works better than a software restart (cron reboot).
 
Update: I gave up restarting the router every week (about 3 weeks ago). I had an incident where the issue showed up a few days after restart.

However, currently, the uptime is > 10 days, and there are 2 settings I changed.

1. I disabled beamforming (2.4Ghz and 5Ghz)

2. I (properly) enabled STP. The powerline adapter is a Level 2 device and I thought enabling Spanning Tree Protocol is the way to go. The STP was activated (LAN - Switch Control) but it looks the setting is not doing anything (I posted about it here). Basically, I added
Code:
brctl stp br0 on
in the init-start script.
 
Update: I had to reboot the router (18 days uptime).

The LAN was OK, but the WAN (PPPoE) was disconnected. The log shows lots of entries like this:
Code:
Timeout waiting for PADO packets
about 1 minute apart.

Nothing worked (restart interface via scMerlin, manually disconnect / connect from WAN) but reboot. I checked the forums, and there are related posts. No solution.

I foresee ChkWAN in my future..
 
Update: I had to reboot the router (28 days uptime).

The WAN stopped working and router became nonresponsive (no answer to ping, no GUI). However, it looks like DHCP service was OK.
 
Did you disable Universal Beamforming for both 2.4G and 5G?
I had success disabling the above, previously it was having issues every 72hrs.
The router has been up and working with no issues for over 35 days now, *knock on wood*.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top