AX-88U disconnecting from ISP

[Ola Malmstrom]

I have the latest Merlin FW 384.19 installed on the router.

Since the update; I have started to get occasional disconnections from my ISP. The router loses contact with my ISP (Bahnhof) and reports that the ISPs DHCP isn't working correctly. Rebooting the router seems to resolve the problem - until it occurs again.

I used to have SKYNET installed but removed it a few days ago to see if this helped in any way. It didn't. I also have a VPN server I use to reach a NAS located in my brother in law's house. This still works fine.

I get a lot of entries in the log file: "Aug 27 08:16:47 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22"

I attach the log file which of course contains a lot of details.

Would be very happy if someone could help me identify the problem!

 

[MaziahBebop]

Log not attached....

 

[Ola Malmstrom]

Don't know how I could miss it.....! Thanks!!

 

[John Fitzgerald]

Don't know how I could miss it.....! Thanks!!

Your AX88:

Had a similar issue with AX58.

You should make a a backup of the system settings and the JFFS Partition.

Then check box to wipe JFFS partition, scroll down and hit apply.

Then use the GUI to Factory Reset (check box to wipe log areas)

Once this is done log in and reapply backup settings (reboot)

Add back JFFS settings (reboot)

Then go and update any scripts by getting updated definitions: (Diversion, update blocking list, B - 4) (Skynet, update blocking, #3) (Unbound, just use option 1)

 

[Vexira]

Under Wan set change form agressive to contious

 

[Ola Malmstrom]

Thanks both!! Seems like I may have two separate problems. Are the DHCP disconnection and the error message that occurs every second unrelated?

The error message doesn't seem to affect performance, CPU usage or RAM. It also doesn't seem to affect operations in any way. So I changed the DHCP setting to "Normal" (not "Continuous" as suggested). I'll wait a few days to see what happens before I try the reset to factory option.

The reason for this is that:

• I remember having read somewhere that when resetting to factory, saved settings shouldn't be imported. Instead a full, manual re-configuration should be done.
• If the DHCP disconnect issue is resolved, I can wait until I have time to do the full factory reset. This will take some time and will create problems for the rest of my family if I'm not careful.

 

[John Fitzgerald]

Thanks both!! Seems like I may have two separate problems. Are the DHCP disconnection and the error message that occurs every second unrelated?

The error message doesn't seem to affect performance, CPU usage or RAM. It also doesn't seem to affect operations in any way. So I changed the DHCP setting to "Normal" (not "Continuous" as suggested). I'll wait a few days to see what happens before I try the reset to factory option.

The reason for this is that:

• I remember having read somewhere that when resetting to factory, saved settings shouldn't be imported. Instead a full, manual re-configuration should be done.
• If the DHCP disconnect issue is resolved, I can wait until I have time to do the full factory reset. This will take some time and will create problems for the rest of my family if I'm not careful.

I don't think you need to start from scratch.
What I explained above is a reset but not a destructive one, in that I didn't pull the USB drive or reformat it.(EXT4 with Journaling ON)
It took less time and worked.
My first attempt, I only did a "factory Reset", without wiping the JFFS Partition. (worked a very short time)
Second attempt I did both.
This problem started with the .19 alpha's, through beta's then Final Release Build.

 

[Ola Malmstrom]

OK understand thanks! Will do it in a few days when the rest of my family is not affected..... Will need to go up early around 5 AM to have enough time if needed.

Will wait & see if the DHCP disconnect happens again first.

Also, I usually want to understand what I'm doing. I have a suspicion there are more than one problems here. The error message seems to be related to eth6 which as far as I understand is the 2.4 GHz band. What is the connection between the continuous error message (every second) and the contents of the JFFS partition?

 

[Vexira]

The reason I suggested contious mode is because your ISP might not like you using agressive mode or normal mode.

I personally use contious mode + a Mac clone of my ISP modem/ router, it fixed my dhcp lease issue which were giving me a headache.

Contious mode keeps the connection going, agressive and normal mode have a time out of a connection is unsuccessful, where as contious doesn't have a time out period.

 

[Ola Malmstrom]

Just performed the activities exactly as described above by John. Aggressiveness is set to "Normal". It seemed to work at first.

However after a couple of minutes the same error message re-appeared: "Aug 30 07:22:05 RT-AX88U-A8B8 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22".

Everything seems to work fine except that the error message appears every second. Should I disregard the message or is there something else I can do?

Note: Tried to attach the log file but can't for some reason.....

 

[octopus]

Just performed the activities exactly as described above by John. Aggressiveness is set to "Normal". It seemed to work at first.

However after a couple of minutes the same error message re-appeared: "Aug 30 07:22:05 RT-AX88U-A8B8 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22".

Everything seems to work fine except that the error message appears every second. Should I disregard the message or is there something else I can do?

Note: Tried to attach the log file but can't for some reason.....

I have same provideras you, I'm on fibre connection and don't have this problem. I,m using Agressive mode but Normal mode working fine to.
eth6/7 is usually radio 2.5/5.0 I think you have to look at this to troubleshort your problem.
Do you use Aimesh nodes?

 

[Ola Malmstrom]

Hi Octopus, no, I don't have any aimesh nodes. The AX88U is the main router, an AC87U is an AP at the other end of the house and finally an old Belkin 1900 router also as AP in another spot to cover the whole house. Like a triangle.

The roaming between the nodes works fine. In order to get it to work properly I have closed the 2.4 GHz network on the Belkin router and added some of the devices to the 2.4 GHz Wireless MAC filter on both ASUS routers to get the devices to roam the way I want. This setup has been in place for months, long before the error started to appear, but since it is related to the 2.4 GHz band I have some suspicions.

 

[Ola Malmstrom]

Had previously been running in WAN DHCP "Aggressive" mode for a long time without issues. Then the disconnect started to happen - always corrected with a router reboot. Finally I changed the mode to "Continuous" which worked for about a week. Suddenly I got two disconnects. The second one about 30 minutes after the first one. Re-set the mode to "Normal" before the second reboot. This has now been running for three days without any issues. We'll see how long it lasts.

I have been in touch with the ISP (Bahnhof) and asked why my connection was dropped at the time documented in the logs. They don't have access to the fiber supplier's logs so they couldn't tell me what had happened. Also tried to discuss the disconnect issue and my suspicion that it had something with the WAN DHCP mode. They couldn't help there either.

 

[Ola Malmstrom]

No matter what WAN DHCP setting I use. Normal seems to work best, but sooner or later I am disconnected and get the error message "ISP DHCP server not working correctly". The ISP can't tell me why. Could there be a HW fault with my AX88U ?

 

[honu]

For what it is worth, I have had the same problem with 384.19; done all of the resets people have suggested, and tried various WAN settings to no avail. It seems to take about a week. Every Sunday morning, usually pretty early, the connection goes. Only once, however, was there an alert on the AX88U about the ISP DHCP server not working correctly. I can work around the issue by clicking on the Globe graphic next to Internet Status to bring up the panel that has a toggle to turn off the Internet and turn it back on. Do that and it all works again for a week.

In my case, however, there is literally nothing in the logs which indicates what's happening when the connection dies. When it happens (tomorrow) I'll try to check again. Been happening ever since installing 384.19.

I'm currently in "Normal" mode. I think that trying to switch to Continuous actually stopped my Internet connection entirely, and so I had to go back to Normal. Can try again, but, this one has been bugging me for weeks. At least it's consistent with the week, give or take a few hours!

 

[Ola Malmstrom]

It happened again with WAN DHCP = Normal.

I read another thread where it was suggested to remove the MAC address under the WAN setting. (Note: I used the MAC address of a router I got from the ISP). I cleared the field and pressed "Apply" and then re-booted the router. We'll see how long it takes before the connection goes down again. Hopefully it will stay up - but I don't understand why this should make any difference.....

 

[honu]

As I expected, it went down again overnight. The time of the outage was around 0410, based upon established TCP sessions all being broken.

The only thing in the syslog is internal LAN DHCP for clients in my home, and wireless key handshakes, ala:

Sep 27 03:27:06 dnsmasq-dhcp[19548]: DHCPREQUEST(br0) 192.168.x.y ec:b5:fa:aa:aa:aa
Sep 27 03:27:06 dnsmasq-dhcp[19548]: DHCPACK(br0) 192.168.x.y ec:b5:fa:aa:aa:aa Philips-hue
Sep 27 04:24:54 hostapd: eth7: STA ea:47:e0 WPA: group key handshake completed (RSN)
Sep 27 04:24:54 hostapd: eth7: STA d4:a3:3d WPA: group key handshake completed (RSN)
Sep 27 04:24:54 hostapd: eth7: STA d4:a3:3d WPA: group key handshake completed (RSN)
Sep 27 04:24:54 hostapd: eth7: STA d4:a3:3d WPA: group key handshake completed (RSN)
Sep 27 04:24:54 hostapd: eth6: STA e8:06:88 WPA: group key handshake completed (RSN)

I modified the MAC addresses of the systems, but, you get the idea. Nothing is omitted here - 0327 for the DHCP on the Hue device, next entry was after the Internet was gone/down.

This time, I moved the WAN mode to continuous, and, the connection did come back up. Will see what happens next week at this time.

(Edited this post with more complete information from the syslog)

 

[honu]

I have a bit more data to share for anyone looking into this (not sure if anyone is). The Router is definitely releasing the DHCP lease to my ISP, and not renewing it, which is resulting in the disconnects. I've tried Normal, Aggressive and Continuous mode, no help. I also have a static IP address from my provider, and, using the static values instead of assigning automatically fails for IPv4 entirely (IPv6 works, as it's using "Native" mode and not Static IPv6).

Fortuitously, I work for my provider and have access to the RADIUS/DHCP logs for my connection and can see this when it died this morning:

10/03/2020  5:10:11 name/dhcp/1 Activity Server 0 04619 Server received a DHCPRELEASE R115564347 xid 0 from:CID: <AX88U MAC> MAC: 1,6,<AX88U MAC> via: Interface 10.a.b.c, 5 in use.

Now the MAC address that I'm using on my ASUS is one that was one of my first WAN MAC addresses for a router the provider sent me; I have just been using that on the WAN interface ever since as I wasn't sure if the static IP would assign otherwise.

As a part of poking at this this morning, I removed the WAN MAC address and let the ASUS use whatever it wanted. No ISP connection at all if I did that, including if I used DHCP.

So, whatever is happening SEEMS to be the ASUS releasing the DHCP lease without being asked to by me, resulting in a disconnect that never re-connects.

Unrelated, but interesting, as part of either Normal or Continuous mode, I see in the DHCP server logs:

10/03/2020 6:50:27 name/dhcp/1 Info Configuration 0 04630 The server could not return the 'option-249', 'ntp-servers', 'static-routes' option(s) requested by Client: CID: 01:<AX88U MAC> MAC: 1,6,<AX88U MAC> packet R115660564.

That's present every two hours:

2020-10-02 12:05:49
2020-10-02 14:05:49
2020-10-02 16:05:50
2020-10-02 18:05:50
2020-10-02 20:05:50
2020-10-02 22:05:50

(In the DHCP server logs).

If I look at the DHCPRELEASEs received by the server by my ASUS, they all correspond to exactly when the ASUS loses the network, and doesn't regain it unless I manually tell it to:

2020-09-20 05:10:25
2020-09-27 05:10:19
2020-09-30 03:35:37
2020-10-03 05:10:11

I'm really not sure what to do here; there is nothing in syslog on the ASUS to indicate what it is doing and why, the Internet is just disconnected/released, and does not renew.

Any suggestions are most welcome!

 

[Ola Malmstrom]

Got disconnected again. This is part of the log file. :

Then a lot of similar records as well as lost internet connection until I re-booted at 19:12:

At 19:13 the WAN connection was restored:

Then a lot of more records most of which seems to br related to local DHCP requests and my 2 VPN servers. Everything seems to work fine now - until next time..?

This does not tell me anything but maybe someone else has a clue?

I don't remember having this problem on 384.17 or earlier. Should I just re-install 384.17?

 

[Ola Malmstrom]

Normally, I have about 10 wired, 8 2.4 GHz and 6 5GHz clients.

When we have visitors the # of wireless connections is increased to 20-25 (ipads/iphones/apple watches). Could this really overload my router?

Most of the times when the internet connection has been lost we had guests....... is there a connection here or is it just a coincidence?