What's new

GT AX 6000

  • 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!

Michael James

Occasional Visitor
A couple times a day my network goes down. I have a GT AX6000 and 4 mesh nodes. The GT AX6000 is reporting this:

Feb 17 16:18:35 roamast: sta[B6:50:8C:12:D4:CC] on ap[58:11:22:28:67:3C], rcpi is 86 and rssi is -67
Feb 17 16:19:37 wan: finish adding multi routes
Feb 17 16:19:37 miniupnpd[3233]: shutting down MiniUPnPd
Feb 17 16:19:37 miniupnpd: it is advised to use network interface name instead of 192.168.50.1/255.255.255.0
Feb 17 16:19:37 miniupnpd[3591]: HTTP listening on port 38277
Feb 17 16:19:37 miniupnpd[3591]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 17 16:19:37 rc_service: udhcpc_wan 3478:notify_rc stop_samba
Feb 17 16:19:37 rc_service: udhcpc_wan 3478:notify_rc start_samba
Feb 17 16:19:37 rc_service: waitting "stop_samba" via udhcpc_wan ...
Feb 17 16:19:37 Samba Server: smb daemon is stopped
Feb 17 16:19:38 wan_up: Find a 2.5G port on [eth0]
Feb 17 16:19:39 ping_target_with_size: Ping test is complete.
Feb 17 16:19:39 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
Feb 17 16:19:40 WAN(0) Connection: WAN was restored.
Feb 17 16:19:41 ping_target_with_size: Successful to ping target(97.149.217.153) with size(79)
Feb 17 16:19:41 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
Feb 17 16:23:40 roamast: sta[B6:50:8C:12:D4:CC] on ap[7C:10:C9:7D:26:EC], rcpi is 60 and rssi is -8
 
Are there any message prior to these? It looks like your WAN connection dropped out. Check your modem's logs.

Also, a DHCP lease of 60 seconds is not normal. You don't usually see that unless your ISP is performing maintenance.
 
Are there any message prior to these? It looks like your WAN connection dropped out. Check your modem's logs.

Also, a DHCP lease of 60 seconds is not normal. You don't usually see that unless your ISP is performing maintenance.
Attaching the SysLog from today. Not sure its happened yet today. I am a newbie when it comes to this area. When it happened yesterday, my wife and I were both streaming 1080p via Bravo for her on a 5Ghz Channel and I was watching 4K over ethernet from Prime Video (The Expanse). Im using Verizon Home Internet in passthru mode (White Box, Green Light for passthru). Getting 225 to 350 down and 20 up depending on the time of day (5G Ultrawide band). Main gt-ax6000 and a mesh network using 4 RT-AX82U's nodes. Have around 12 cameras indoor and outdoor in around 2500 square foot main floor and 2500 square foot basement that has concrete on the 1 side. Some of the cameras have weak antennae so I am boosting those by running them thru a RT-AX82U which has 4 antennae (Ethernet and some are POE). Those nodes are all 5ghz channels back to the the main RT-AX82U

Roaming Assistant is on with Disconnect clients with RSSI lower than : -70 dBm
I have 2 devices with manually assigned IPs around the DHCP, AppleTV4k which I use a lot and an Alexa Echo.. originally I thought this was a way to set a Static IP for each device?

I'm attaching screenshots of my settings as well.
 

Attachments

  • syslog (1).txt
    322.2 KB · Views: 6
  • Screenshot 2024-02-18 085017.png
    Screenshot 2024-02-18 085017.png
    371.4 KB · Views: 17
  • Screenshot 2024-02-18 084909.png
    Screenshot 2024-02-18 084909.png
    815.4 KB · Views: 15
  • Screenshot 2024-02-18 084831.png
    Screenshot 2024-02-18 084831.png
    829.5 KB · Views: 15
  • Screenshot 2024-02-18 083025.png
    Screenshot 2024-02-18 083025.png
    197.6 KB · Views: 16
Here are 2 more screenshots
 

Attachments

  • Screenshot 2024-02-18 085713.png
    Screenshot 2024-02-18 085713.png
    485.6 KB · Views: 18
  • Screenshot 2024-02-18 085637.png
    Screenshot 2024-02-18 085637.png
    865.1 KB · Views: 17
I just noticed that DHCP Query Frequency was set to "Aggressive Mode" by default (since I have never changed this) under Special Requirements from ISP. I changed it to Normal Mode. Is that recommended?
 
I just noticed that DHCP Query Frequency was set to "Aggressive Mode" by default (since I have never changed this) under Special Requirements from ISP. I changed it to Normal Mode. Is that recommended?
I have mine set to Aggressive but some ISP's don't like that apparently. I've never seem a problem with Aggressive myself but YMMV.

Unfortunately your log file isn't helpful. It's swamped with thousands of roamast messages which means it only covers a four hour period and anything useful has been lost.

It would be more useful to see any logs from the Verizon box if it has such a thing. I suspect your problems are there rather than with your router.
 
I have mine set to Aggressive but some ISP's don't like that apparently. I've never seem a problem with Aggressive myself but YMMV.

Unfortunately your log file isn't helpful. It's swamped with thousands of roamast messages which means it only covers a four hour period and anything useful has been lost.

It would be more useful to see any logs from the Verizon box if it has such a thing. I suspect your problems are there rather than with your router.
Not sure how to look at Verizon box logs when its in passthru mode. Will need to research.
Should I turn off Roamast?
Are my Roamasst messages showing any issues?
Should I change the Roaming Assistant is on with Disconnect clients with RSSI lower than : -70 dBm to -80 dBm?
 
This just occured:
Feb 18 08:54:43 roamast: [EXAP]Deauth old sta in 1 0: B6:50:8C:12:D4:CC
Feb 18 08:54:43 roamast: eth7: disconnect weak signal strength station [b6:50:8c:12:d4:cc]
Feb 18 08:54:43 roamast: eth7: remove client [b6:50:8c:12:d4:cc] from monitor list
Feb 18 08:54:44 wlceventd: wlceventd_proc_event(662): eth7: Disassoc B6:50:8C:12:D4:CC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 18 09:09:37 rc_service: httpd 2567:notify_rc restart_wan_if 0;restart_stubby
Feb 18 09:10:47 wan: finish adding multi routes
Feb 18 09:10:47 miniupnpd[3100]: shutting down MiniUPnPd
Feb 18 09:10:47 miniupnpd: it is advised to use network interface name instead of 192.168.50.1/255.255.255.0
Feb 18 09:10:47 miniupnpd[2983]: HTTP listening on port 33973
Feb 18 09:10:47 miniupnpd[2983]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 18 09:10:47 rc_service: udhcpc_wan 2873:notify_rc stop_samba
Feb 18 09:10:47 rc_service: udhcpc_wan 2873:notify_rc start_samba
Feb 18 09:10:47 rc_service: waitting "stop_samba" via udhcpc_wan ...
Feb 18 09:10:47 Samba Server: smb daemon is stopped
Feb 18 09:10:47 WAN(0) Connection: WAN was restored.
Feb 18 09:10:48 wan_up: Find a 2.5G port on [eth0]
Feb 18 09:10:49 ping_target_with_size: Ping test is complete.
Feb 18 09:10:49 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
Feb 18 09:10:51 ping_target_with_size: Successful to ping target(97.149.217.153) with size(79)
Feb 18 09:10:51 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
 
Should I change the Roaming Assistant is on with Disconnect clients with RSSI lower than : -70 dBm to -80 dBm?

If you want your clients to be disconnected earlier - change it to -60dBm. Lower numbers are stronger signal level.
 
If you want your clients to be disconnected earlier - change it to -60dBm. Lower numbers are stronger signal level.
I dont understand what Roam Asst actually does. I think it disconnects when signal levels are lower than the threshold. Which I assume disconnects my mesh nodes or individual devices? (Do the logs show that a mesh node is too far away?)
Also, I need a cleanup Log so I was going to turn both the 5ghz and 2.5 Romaasst OFF for a couple days
 
It makes an attempt to switch the device to a better signal AP (or "node" in your case) by disconnecting it from the current AP. This doesn't guarantee better roaming. Most devices will still re-connect to the same AP. Roaming Assistant also doesn't work properly in some firmware versions. Your roaming issue is too much Wi-Fi from 5x routers and I'm in doubt you can fix it easily. Your WAN issue is unrelated though. I remember your main router reset itself some time ago. There is something else going on there.
 
This just occured:
Feb 18 08:54:43 roamast: [EXAP]Deauth old sta in 1 0: B6:50:8C:12:D4:CC
Feb 18 08:54:43 roamast: eth7: disconnect weak signal strength station [b6:50:8c:12:d4:cc]
Feb 18 08:54:43 roamast: eth7: remove client [b6:50:8c:12:d4:cc] from monitor list
Feb 18 08:54:44 wlceventd: wlceventd_proc_event(662): eth7: Disassoc B6:50:8C:12:D4:CC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 18 09:09:37 rc_service: httpd 2567:notify_rc restart_wan_if 0;restart_stubby
Feb 18 09:10:47 wan: finish adding multi routes
Feb 18 09:10:47 miniupnpd[3100]: shutting down MiniUPnPd
Feb 18 09:10:47 miniupnpd: it is advised to use network interface name instead of 192.168.50.1/255.255.255.0
Feb 18 09:10:47 miniupnpd[2983]: HTTP listening on port 33973
Feb 18 09:10:47 miniupnpd[2983]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 18 09:10:47 rc_service: udhcpc_wan 2873:notify_rc stop_samba
Feb 18 09:10:47 rc_service: udhcpc_wan 2873:notify_rc start_samba
Feb 18 09:10:47 rc_service: waitting "stop_samba" via udhcpc_wan ...
Feb 18 09:10:47 Samba Server: smb daemon is stopped
Feb 18 09:10:47 WAN(0) Connection: WAN was restored.
Feb 18 09:10:48 wan_up: Find a 2.5G port on [eth0]
Feb 18 09:10:49 ping_target_with_size: Ping test is complete.
Feb 18 09:10:49 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
Feb 18 09:10:51 ping_target_with_size: Successful to ping target(97.149.217.153) with size(79)
Feb 18 09:10:51 dhcp client: bound 97.149.217.152/255.255.255.240 via 97.149.217.153 for 60 seconds.
This looks like you changing the DHCP aggressive/normal setting.
 
Can anyone take a look at these logs and maybe tell me whats happening. Just lost connectivity at around 7pm EST. And there may be other things going on but I am not good at reading these logs.

FYI I turned off Roamasst for both the 5ghz and 2.5 yesterday so I can get a better read.

Syslog attached
 

Attachments

  • syslog (2).txt
    23 KB · Views: 7
Was it only a wired PC that lost connectivity to the internet?
I think it was other devices.

But then last night, something else happened .. I started notices devices around the house lost connectivity. *** Please take a look at the attached log***. Something happened where it thinks its May 5th not February 19th and then started running a bunch of "stuff". Am I being hacked? I am running the STOCK Asus firmware from Asus. I have Auto update OFF for firmware. But then I notice it talks about "Merlin"? So could someone be trying to hack the router by installing a different firmware? Or is this just normal?

For example:
May 5 01:05:15 kernel: MerlinSupport::merlin16_serdes_init(): Step 4. Assert micro reset
.....
This section starts off as;
May 5 01:05:15 kernel: klogd started: BusyBox v1.24.1 (2023-06-10 17:57:02 CST)
May 5 01:05:15 kernel: Linux version 4.19.183 (gitserv_asus@bpza001bud) (gcc version 9.2.0 (Buildroot 2019.11.1)) #1 SMP PREEMPT Sat Jun 10 17:58:52 CST 2023

In the PC/Web interface:
The current version of the main router is reporting: 3.0.0.6.102_21514-g9affda2_136-g5d23c
The AI Mesh nodes are: 3.0.0.4.388_24231-gbc11d13
 

Attachments

  • syslog (3).txt
    120.6 KB · Views: 8
Last edited:
No you're not being hacked. The "Merlin" messages are nothing to do with RMerlin's firmware, it's the internal name Broadcom uses for the network switch.

The reason for the May 5th is because your router rebooted, hence your temporary lack of connectivity.

Unfortunately there's no clue in the log as to why it rebooted. It appears to have just spontaneously happened. Of course it's also possible that it crashed so fast that it didn't have time to write anything to the log file.

Possible reasons could be 1) power supply to the router was interrupted, 2) router has faulty hardware, 3) firmware bug, 4) something else.

We've seen a few reports of this sort of failure but as far as I know there's been no definitive reason found. If the router is still under warrantee I'd suggest you return it as faulty. If that's not possible my next suggestion would be to downgrade the firmware to the previous version and see if that's more stable.
 
No you're not being hacked. The "Merlin" messages are nothing to do with RMerlin's firmware, it's the internal name Broadcom uses for the network switch.

The reason for the May 5th is because your router rebooted, hence your temporary lack of connectivity.

Unfortunately there's no clue in the log as to why it rebooted. It appears to have just spontaneously happened. Of course it's also possible that it crashed so fast that it didn't have time to write anything to the log file.

Possible reasons could be 1) power supply to the router was interrupted, 2) router has faulty hardware, 3) firmware bug, 4) something else.

We've seen a few reports of this sort of failure but as far as I know there's been no definitive reason found. If the router is still under warrantee I'd suggest you return it as faulty. If that's not possible my next suggestion would be to downgrade the firmware to the previous version and see if that's more stable.
Thx Colin. Its still under warranty. I think I'll go that route.
 
No you're not being hacked. The "Merlin" messages are nothing to do with RMerlin's firmware, it's the internal name Broadcom uses for the network switch.

The reason for the May 5th is because your router rebooted, hence your temporary lack of connectivity.

Unfortunately there's no clue in the log as to why it rebooted. It appears to have just spontaneously happened. Of course it's also possible that it crashed so fast that it didn't have time to write anything to the log file.

Possible reasons could be 1) power supply to the router was interrupted, 2) router has faulty hardware, 3) firmware bug, 4) something else.

We've seen a few reports of this sort of failure but as far as I know there's been no definitive reason found. If the router is still under warrantee I'd suggest you return it as faulty. If that's not possible my next suggestion would be to downgrade the firmware to the previous version and see if that's more stable.

Actually, before I send it back, what would the most stable firmware be and where can I get the download?
Also, should I downgrade each mesh node as well on firmware?
 
Actually, before I send it back, what would the most stable firmware be and where can I get the download?
I have no idea about which is the most stable firmware. You'd have to test it yourself by trial and error. You can download the firmware from Asus' website. Remember to disable automatic firmware updates.


I've just noticed you're using firmware 3.0.0.6.102_21514 which is the very first release of ASUSWRT 5.0. Initial software releases often have issues. The previous firmware version is 3.0.0.4.388_23285 from the more established "3.0.0.4" branch. If you were to install this older firmware you would need to follow it with a hard factory reset because the two branches are significantly different.

Also, should I downgrade each mesh node as well on firmware?
Sorry, I can't comment as I don't use AiMesh.
 
So this is confusing. I have a Reolink Video Doorbell, purchased last year. In the Reolink camera software on the PC, its configured for a static IP address 151. In the Android software, same thing, shows IP address 151. In the Blue Iris camera software, it shows and configures for 151. When I look in the GT-AX6000 menu under clients, it says Static IP but shows 150 not 151?
 

Latest threads

Sign Up For SNBForums Daily Digest

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