What's new

Disassociated because sending station is leaving (or has left)

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

DTS

Regular Contributor
Our Android phones will not connect to the Asus AP. I know there are a lot of threads on this topic. I understand the issue is Asus-specific, but not limited to a specific firmware. (Is that correct?)

It seems like I have tried almost everything, short of reflashing. I want to try to better understand the issue so my troubleshooting doesn't consist entirely of trying random things.

Here's some background for my situation:

model: RT-AC68P
firmware: Merlin 386.7
recent changes: none. flashed firmware 2022-06-22.
device config: it's just an AP. I don't have any mesh configured. I don't have any guest networks either. Very basic.
Wireless Authorization is WPA2-Personal. WPS has never been used.
Most wireless settings were default / auto until I started troubleshooting this issue.

In hindsight, the problem apparently began a while back when one Android phone in the family would not connect to the AP. Nobody had time to investigate, and the person just stopped using our WiFi on that phone. During this time one laptop and two other Android phones had no trouble connecting and staying connected to the AP.

However, now none of the Android phones will connect. The errors shown in the log are always exactly the same:

Code:
Oct 22 16:58:53 syslog: wlceventd_proc_event(527): eth2: Auth 2C:4C:C6:AA:BB:CC, status: Successful (0), rssi:0
Oct 22 16:58:53 syslog: wlceventd_proc_event(556): eth2: Assoc 2C:4C:C6:AA:BB:CC, status: Successful (0), rssi:0
Oct 22 16:59:11 syslog: wlceventd_proc_event(508): eth2: Disassoc 2C:4C:C6:AA:BB:CC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:-52

The router wireless log briefly shows the device as connected.
  • This is not limited to 5GHz. I get the same log messages and same issue on 2.4GHz.
  • I see the same log msg (different MAC) for each different Android device I test.
  • Disconnected all clients (which was just the laptop), but still no single Android device we have will connect.
Some of the things I tried:
  • Changing wireless mode to 'Legacy'. Did not resolve it, so reverted.
  • Changing 5 GHz channel bandwidth to '40 MHz'. Did not resolve it, so reverted.
  • Disable Universal Beamforming. Did not resolve it, so reverted.
  • Change 5 GHz control channel from Auto to 36. Did not resolve it, but left this setting.
  • Disable universal beamforming
  • Change group key rotation interval to a very short or very long value. Did not resolve it, so reverted to 3600.
  • Reboot router while also doing "Forget" WiFi settings on phone, then re-entering credentials. Did not resolve it.
More notes:
  • Firmware 386.7 is supposed to be a working version, right?
  • We do not have any Apple devices connected to this AP. Never have.
  • I did not recently upgrade or change any settings, yet the problem strangely "expanded" to affect all Android devices.
As I mentioned, I feel like I am randomly trying things without any understanding of the underlying issue. What causes this? What is the goal of making the various changes suggested in other thread?
 
You can see this behaviour from clients if they can't connect to the internet or they think their DNS isn't working. Have you messed with DNS on your network or implemented any blocking?
 
Just thought I would share my experience with this. I tracked it down to having Wifi and Eth backhaul both enabled (with it set to Backhaul Connection Priority of 5ghz-2 Wifi First). Now this was working fine for months as it was.. but something in the eth backhaul seems to have caused issue when I was rearraging my switches and devices to get SMB3 running optimally. The AI Mesh node was previously connected fine with Wifi backhaul, but after rearraging the switches and devices plugged in, all phones would go Connected, No Internet. Unplugging the Eth Backhaul fixed it.. but that shouldn't be the case. I am working on getting things reset back up and going to see if I can get it running as it was before. Perhaps I will set it to only Wifi, or only Eth Backhaul.
 
Just thought I would share my experience with this. I tracked it down to having Wifi and Eth backhaul both enabled (with it set to Backhaul Connection Priority of 5ghz-2 Wifi First). Now this was working fine for months as it was.. but something in the eth backhaul seems to have caused issue when I was rearraging my switches and devices to get SMB3 running optimally. The AI Mesh node was previously connected fine with Wifi backhaul, but after rearraging the switches and devices plugged in, all phones would go Connected, No Internet. Unplugging the Eth Backhaul fixed it.. but that shouldn't be the case. I am working on getting things reset back up and going to see if I can get it running as it was before. Perhaps I will set it to only Wifi, or only Eth Backhaul.

If you run eth backhaul through a switch, the switch must be capable of passing VLAN tagged frames. My guess is yours isn't, or you haven't configured the vlans on the new ports. Thus the Ethernet backhaul is connected but can't pass the traffic causing issues for the clients connected to it (especially ones on guest wireless).
 
If you run eth backhaul through a switch, the switch must be capable of passing VLAN tagged frames. My guess is yours isn't, or you haven't configured the vlans on the new ports. Thus the Ethernet backhaul is connected but can't pass the traffic causing issues for the clients connected to it (especially ones on guest wireless).
Can you remind me what VLAN ID is used to communicate with the nodes? I know the first guest Wi-Fi's use 501 and 502.

EDIT: The more I rack my aging brain I seem to remember that the AiMesh communication doesn't use VLANs (other than for those guest networks), instead it uses a normal client/server process (cfg_server and cfg_client). In which case @dethknite's problem is more likely to be a cabling error.

With all that said I don't think @dethknite's problem has anything to do with the subject of this thread. The original problem was about Android phones connecting to an access point. AiMesh wasn't being used.
 
Last edited:
Can you remind me what VLAN ID is used to communicate with the nodes? I know the first guest Wi-Fi's use 501 and 502.

EDIT: The more I rack my aging brain I seem to remember that the AiMesh communication doesn't use VLANs (other than for those guest networks), instead it uses a normal client/server process (cfg_server and cfg_client). In which case @dethknite's problem is more likely to be a cabling error.

With all that said I don't think @dethknite's problem has anything to do with the subject of this thread. The original problem was about Android phones connecting to an access point. AiMesh wasn't being used.
Yes as far as I know regular comms are VLAN 1 but if the 50x aren't passing it won't come up, at least according to others that have had the same issue. Once they add the 50x to their switch the backhaul comes up.

Seems related as they said all phones stopped working when they recabled the node (which is just an AP).
 
Yes as far as I know regular comms are VLAN 1 but if the 50x aren't passing it won't come up, at least according to others that have had the same issue. Once they add the 50x to their switch the backhaul comes up.
Reading some of the past posts it sounds like AiMesh doesn't necessarily use VLAN tagging at all (1 or otherwise), other than for 50x. Maybe 802.1q (and VLAN 1) is only used when guest networks (#1) are enabled. Someone with a managed switch would have to confirm/deny that though.

Seems related as they said all phones stopped working when they recabled the node (which is just an AP).
I don't see the relationship. The OP said "it's just an AP. I don't have any mesh configured." Whereas @dethknite is talking about an AiMesh backhaul problem. His phones have no problem connecting to the AP, unlike the problem OP was having.
 
Last edited:
Reading some of the past posts it sounds like AiMesh doesn't necessarily use VLAN tagging at all (1 or otherwise), other than for 50x. Maybe 802.1q (and VLAN 1) is only used when guest networks (#1) are enabled. Someone with a managed switch would have to confirm/deny that though.


I don't see the relationship. The OP said "it's just an AP. I don't have any mesh configured." Whereas @dethknite is talking about an AiMesh backhaul problem. His phones have no problem connecting to the AP, unlike the problem OP was having.

If guest isn't enabled (or if it is enabled with "access intranet" enabled) then it doesn't create the 50x VLANs on my router, but I've never tried it in AiMesh, I'm assuming the behavior is the same. So if guest isn't enabled then it should work through any switch. When guest 1 is enabled with intranet disabled, It definitely does an 802.1Q trunk with VLAN 1 untagged and the 50x VLANs tagged, it actually adds them tagged to every LAN port (used to put them on the WAN too but that caused problems, I think now it only does it on the nodes). I removed them from the LAN ports I'm not using them on, even though technically it doesn't hurt anything. Have worked with a couple on this forum to configure the VLANs in their switches, at which point it all started working (they couldn't even get to the management of the nodes from what I recall, so it seems like if the router detects an issue it totally disables the wired backhaul). My guess here is since this person moved switches around they're having a similar issue but just a guess.

Didn't read through the whole thread, just replying to this particular person, not sure if the original issue was not connecting at all or connecting but no internet etc. But the mesh node is essentially just an AP, granted with that extra AiMesh VLAN stuff going on.

VLAN 1 is always present, it is untagged on all ports but tagged to the CPU (but that doesn't affect anything, just a weird way Asus set it up).
 
VLAN 1 is always present, it is untagged on all ports but tagged to the CPU (but that doesn't affect anything, just a weird way Asus set it up).
That was true on the old RT-AC68U class of routers (c.f. robocfg) but I don't think the same applies to the HND routers. At least it's not obvious to me.

But as far as a connecting to a separate switch is concerned, untagged means exactly that, no VLAN information (1 or otherwise) is sent over the wire. So in theory, if you're not using isolated guest networks any old dumb switch should work.
 
That was true on the old RT-AC68U class of routers (c.f. robocfg) but I don't think the same applies to the HND routers. At least it's not obvious to me.

But as far as a connecting to a separate switch is concerned, untagged means exactly that, no VLAN information (1 or otherwise) is sent over the wire. So in theory, if you're not using isolated guest networks any old dumb switch should work.

Yes absolutely, if you're not using guest, you can run it via any switch, at least that is my understanding, I have not seen anyone with an output showing some special VLAN for Aimesh control etc.

From what I recall one of the ones having the issue was HND. Without robocfg you have to look at the vlanctl and vconfig (I think, working off memory here) to see what is set up but as far as I know the guest 50x are still tagged on all ports and needed for backhaul if Guest 1/no intranet is configured.
 
I don't use VLANs, and the ETH backhaul is plugged directly from one AC-5300 to the other AC-5300 over powerline. I decided to just factory reset the node and set it back up and all is working good with ETH backhaul, Wifi, as well as just auto.
 
I don't use VLANs, and the ETH backhaul is plugged directly from one AC-5300 to the other AC-5300 over powerline. I decided to just factory reset the node and set it back up and all is working good with ETH backhaul, Wifi, as well as just auto.

If you're using Guest Wireless 1, you are using VLANs. Powerline converters can be very hit or miss. You might actually get better speed and reliability with wireless backhaul but you'd have to test both to see.
 
You are correct, and thanks for the tips. I have the powerline Eth/backhaul there as a failsafe / fallback, and the speeds generally are a bit less than the 5Ghz-2. I do not use Guest Wifi, though, and no VLANs, so I still am not quite sure what got bugged up in everything other than something during the course of upgrading firmware on Router and Nodes. Resetting the Node fixed it though.
 

Sign Up For SNBForums Daily Digest

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

Members online

Top