GT-AX6000 Refuses to authorize station

[rutilate]

My Macbook Pro and iPhone stopped connecting to my GT-AX6000 AIMesh. It repeatedly self-assigns a 192.168.1.XXX address, no matter how many times I release and renew the DHCP lease. I can connect to the Guest network just fine, oddly enough.

These devices are within 20 feet from the primary station. They've both been connecting fine, and transferring between AI Mesh nodes without consequence during the past two months. Three days ago I'm not able to connect via either iPhone or Macbook no matter how many times that I refresh the IP address or turn off wifi or restart the router.

The log files are littered with the MAC address of my laptop and iPhone being rejected (first batch), or auth/deauth (second batch).

The first batch looks like the A8:98 device (laptop) is being transitioned to the primary router (DD:6C)connected to the modem, and failing to get a response. However, I'm sitting here on the laptop trying to refresh the IP address during this time. In the second batch, I'm also trying to connect and then being self-assigned an IP address.

Interestingly, I can self-assign an IP address in the proper range and access the network, so I'm technically connected to the router.

Any ideas as to why I cannot obtain a proper IP address on these 2 devices?


Jul 22 09:55:43 bsd: bsd: Sending act Frame to AA:AA:AA:AA:A8:98 with transition target eth7 ssid 58:11:22:4e:dd:6c
Jul 22 09:55:44 bsd: bsd: STA:AA:AA:AA:AA:A8:98 no response
Jul 22 09:55:44 bsd: bsd: Sending act Frame to AA:AA:AA:AA:A8:98 with transition target eth7 ssid 58:11:22:4e:dd:6c
Jul 22 09:55:45 bsd: bsd: STA:AA:AA:AA:AA:A8:98 no response
Jul 22 09:55:45 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind AA:AA:AA:AA:A8:98, status: 0, reason: Previous authentication no longer valid (2), rssi:-47
Jul 22 09:55:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind AA:AA:AA:AA:A8:98, status: 0, reason: Disassociated due to inactivity (4), rssi:-47
Jul 22 09:55:48 wlceventd: wlceventd_proc_event(685): eth6: Auth D6:80:CD2:9C:12, status: Successful (0), rssi:0
Jul 22 09:55:48 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc D6:80:CD2:9C:12, status: Successful (0), rssi:-67
Jul 22 09:55:50 bsd: bsd: Sending act Frame to b8:f6:b1:19:82:5d with transition target eth7 ssid 58:11:22:4e:dd:6c
Jul 22 09:55:51 bsd: bsd: STA:b8:f6:b1:19:82:5d no response
Jul 22 09:55:51 bsd: bsd: Sending act Frame to b8:f6:b1:19:82:5d with transition target eth7 ssid 58:11:22:4e:dd:6c
Jul 22 09:55:52 bsd: bsd: STA:b8:f6:b1:19:82:5d no response
Jul 22 09:55:53 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind B8:F6:B1:19:82:5D, status: 0, reason: Previous authentication no longer valid (2), rssi:-53
Jul 22 09:55:53 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind B8:F6:B1:19:82:5D, status: 0, reason: Previous authentication no longer valid (2), rssi:-53
Jul 22 09:55:53 crond[2825]: time disparity of 2742470 minutes detected


LATER:

Jul 22 16:04:40 wlceventd: wlceventd_proc_event(685): eth6: Auth ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:0
Jul 22 16:04:40 wlceventd: wlceventd_proc_event(722): eth6: Assoc ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:-75
Jul 22 16:04:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind ZZ:ZZ:ZZ:ZZ:B9:A8, status: 0, reason: Unspecified reason (1), rssi:-75
Jul 22 16:04:46 wlceventd: wlceventd_proc_event(685): eth6: Auth ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:-75
Jul 22 16:04:46 wlceventd: wlceventd_proc_event(722): eth6: Assoc ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:-75
Jul 22 16:05:30 wlceventd: wlceventd_proc_event(685): eth7: Auth ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:0
Jul 22 16:05:30 wlceventd: wlceventd_proc_event(695): eth7: ReAssoc ZZ:ZZ:ZZ:ZZ:B9:A8, status: Successful (0), rssi:-87
Jul 22 16:06:12 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind ZZ:ZZ:ZZ:ZZ:B9:A8, status: 0, reason: Disassociated due to inactivity (4), rssi:-79
Jul 22 16:10:09 wlceventd: wlceventd_proc_event(685): eth6: Auth YY:YY:YY:YY:EA:A9, status: Successful (0), rssi:0
Jul 22 16:10:09 wlceventd: wlceventd_proc_event(722): eth6: Assoc YY:YY:YY:YY:EA:A9, status: Successful (0), rssi:-54
Jul 22 16:10:21 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind YY:YY:YY:YY:EA:A9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 22 16:10:21 wlceventd: wlceventd_proc_event(662): eth6: Disassoc YY:YY:YY:YY:EA:A9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 22 16:10:28 wlceventd: wlceventd_proc_event(662): eth7: Disassoc AA:AA:AA:AA:A8:98, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 22 16:10:28 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind AA:AA:AA:AA:A8:98, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 22 16:10:41 wlceventd: wlceventd_proc_event(685): eth7: Auth AA:AA:AA:AA:A8:98, status: Successful (0), rssi:0
Jul 22 16:10:41 wlceventd: wlceventd_proc_event(722): eth7: Assoc AA:AA:AA:AA:A8:98, status: Successful (0), rssi:-53
Jul 22 16:11:05 wlceventd: wlceventd_proc_event(662): eth7: Disassoc AA:AA:AA:AA:A8:98, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 22 16:11:05 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind AA:AA:AA:AA:A8:98, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 22 16:11:06 wlceventd: wlceventd_proc_event(685): wl1.1: Auth AA:AA:AA:AA:A8:98, status: Successful (0), rssi:0
Jul 22 16:11:06 wlceventd: wlceventd_proc_event(722): wl1.1: Assoc AA:AA:AA:AA:A8:98, status: Successful (0), rssi:-63
Jul 22 16:12:41 wlceventd: wlceventd_proc_event(662): wl1.1: Disassoc AA:AA:AA:AA:A8:98, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 22 16:12:41 wlceventd: wlceventd_proc_event(645): wl1.1: Deauth_ind AA:AA:AA:AA:A8:98, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 22 16:12:41 wlceventd: wlceventd_proc_event(685): eth7: Auth AA:AA:AA:AA:A8:98, status: Successful (0), rssi:0
Jul 22 16:12:41 wlceventd: wlceventd_proc_event(722): eth7: Assoc AA:AA:AA:AA:A8:98, status: Successful (0), rssi:-63

 

[L&LD]

Did you try rebooting (Restart, not Shutdown) the problem devices?

Did you try rebooting the router and/or node?

 

[rutilate]

Did you try rebooting (Restart, not Shutdown) the problem devices?

Did you try rebooting the router and/or node?

Yes absolutely. I even factory reset the node and reconnected it because it appeared to have fallen off the network. Probably a separate issue.

 

[L&LD]

Have you ever factory reset the main router? Without using a saved backup config file? And reset after flashing the firmware you are currently using?

 

[rutilate]

Have you ever factory reset the main router? Without using a saved backup config file? And reset after flashing the firmware you are currently using?

When I first placed them both in service I upgraded the firmware on both and did a hard reset post upgrade. I’ve done so enough while trying to stabilize my XT8s that I’m no stranger to the process.

And I can do it again if necessary.

I’m surprised that it was very stable for the last ~45 days since deployment but then failing miserably suddenly during the last three days.

And I’m certainly hoping I don’t have to hard reset and reconfigure every 2 months…

 

[ColinTaylor]

This sounds like exactly the same problem you reported with your XT8's which is why you replaced it with a GT-AX6000.

XT8: dropping devices, can't connect AI Mesh nodes

I need some help diagnosing some crippling problems. My XT8 router is regularly dropping devices, devices will connect with default IP address (xxx.xxx.1.xxx, should be *.50.xxx), and despite at least 40 tries, will not connect an ethernet-connected node despite multiple factory resets...

www.snbforums.com

If your devices are constantly getting 192.168.1.x addresses from your main LAN (but not on guest networks #1 on each band*) instead of 192.168.50.x I'd say that you've got another device on your LAN acting as a DHCP server.

* or guest networks #2 and #3 when Access Intranet is disabled.

 

[drinkingbird]

This sounds like exactly the same problem you reported with your XT8's which is why you replaced it with a GT-AX6000.

XT8: dropping devices, can't connect AI Mesh nodes

I need some help diagnosing some crippling problems. My XT8 router is regularly dropping devices, devices will connect with default IP address (xxx.xxx.1.xxx, should be *.50.xxx), and despite at least 40 tries, will not connect an ethernet-connected node despite multiple factory resets...

www.snbforums.com

If your devices are constantly getting 192.168.1.x addresses from your main LAN (but not on guest networks #1 on each band) instead of 192.168.50.x I'd say that you've got another device on your LAN acting as a DHCP server.

Yep, never seen anything "self assign" a 192.168 IP. 169.254 is used for windows, not sure about apple. That IP is probably coming from an ISP router or some other rogue device.

 

[drinkingbird]

My Macbook Pro and iPhone stopped connecting to my GT-AX6000 AIMesh. It repeatedly self-assigns a 192.168.1.XXX address, no matter how many times I release and renew the DHCP lease. I can connect to the Guest network just fine, oddly enough.

While you have a 192.168.1.x IP, look at what your default gateway is (probably 192.168.1.1). Go to http:// that IP and see what the rogue DHCP server is, and shut it down.

 

[rutilate]

This sounds like exactly the same problem you reported with your XT8's which is why you replaced it with a GT-AX6000.

XT8: dropping devices, can't connect AI Mesh nodes

I need some help diagnosing some crippling problems. My XT8 router is regularly dropping devices, devices will connect with default IP address (xxx.xxx.1.xxx, should be *.50.xxx), and despite at least 40 tries, will not connect an ethernet-connected node despite multiple factory resets...

www.snbforums.com

If your devices are constantly getting 192.168.1.x addresses from your main LAN (but not on guest networks #1 on each band*) instead of 192.168.50.x I'd say that you've got another device on your LAN acting as a DHCP server.

* or guest networks #2 and #3 when Access Intranet is disabled.

Ok, you're diligent--I'd not made that connection with my own post!! Thanks for digging!

Yep, never seen anything "self assign" a 192.168 IP. 169.254 is used for windows, not sure about apple. That IP is probably coming from an ISP router or some other rogue device.

While you have a 192.168.1.x IP, look at what your default gateway is (probably 192.168.1.1). Go to http:// that IP and see what the rogue DHCP server is, and shut it down.

@ColinTaylor and @drinkingbird you nailed it. This was the critical piece of information that I was missing. It turns out there is a Cisco RV340 VPN in the network switch box left behind by the previous owners.

I ran cable from the ASUS router to the patch panel to run the cameras. I never bothered to examine the 1u box below the patch panel because I wasn't using most of the equipment left over from the previous owners. It never occurred to me that it would also be a DHCP router. Now I know and have yeeted that box.

Someday I'll determine whether or not there is any value in updating the box and putting it back inline from the cable modem.

Thank you both again. You may well have solved a problem that I've been wrestling with for nearly 2 years! I'm pretty sure that all the problems I've had with AIMesh connection failures have been related to this issue where the new device would get a .1.xx IP address instead of a .50.xx IP address and the system would time out because it couldn't find the device. AND, devices would disconnect occasionally in a handoff and then try to reconnect but get a .1.xx address and choke.