Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

[GetToTheChopper!]

I have the same problem. Running Merlin 386.7... Suddenlink today my pixel 4 cannot connect to the 5 gigahertz actually nothing can. I upgraded the firmware yesterday changed a couple of settings. Settings which were all in the Smart Connect rules hasn't changed back. Here is a snippet from my log file

Jul 12 03:45:40 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:40 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind F0:5C:77:B9:53:26, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 12 03:45:40 wlceventd: wlceventd_proc_event(508): eth5: Disassoc F0:5C:77:B9:53:26, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 12 03:45:40 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:41 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0000 is buggy, dev eth0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(527): eth5: Auth F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(556): eth5: Assoc F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind F0:5C:77:B9:53:26, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(508): eth5: Disassoc F0:5C:77:B9:53:26, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:47 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:47 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 wlceventd: wlceventd_proc_event(527): eth5: Auth F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:51 wlceventd: wlceventd_proc_event(556): eth5: Assoc F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:51 dnsmasq-dhcp[8409]: DHCPREQUEST(br0) 192.168.50.205 f0:5c:77:b9:53:26
Jul 12 03:45:51 dnsmasq-dhcp[8409]: DHCPACK(br0) 192.168.50.205 f0:5c:77:b9:53:26 Pixel-4-XL
Jul 12 03:45:52 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:52 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc00c14f2a8 next ffffffc0110cec60 prev ffffffc0110cec60 rep_entry->list ffffffc0110cec60 next ffffffc00c14f2a8 prev ffffffc00c14f2a8
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0

 

[GetToTheChopper!]

Ac86u running Merlin c386.7 I could not get my pixel 4 XL to connect to 5 gigahertz. I did upgrade the firmware router yesterday are closed a couple of cities. But have since changed the settings back without any luck.


Here is a small snippet from my log:


Jul 12 03:45:40 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:40 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind F0:5C:77:B9:53:26, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 12 03:45:40 wlceventd: wlceventd_proc_event(508): eth5: Disassoc F0:5C:77:B9:53:26, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 12 03:45:40 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:41 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:43 kernel: protocol 0000 is buggy, dev eth0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(527): eth5: Auth F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(556): eth5: Assoc F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind F0:5C:77:B9:53:26, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 12 03:45:46 wlceventd: wlceventd_proc_event(508): eth5: Disassoc F0:5C:77:B9:53:26, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 12 03:45:46 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:47 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:47 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:48 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:51 wlceventd: wlceventd_proc_event(527): eth5: Auth F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:51 wlceventd: wlceventd_proc_event(556): eth5: Assoc F0:5C:77:B9:53:26, status: Successful (0), rssi:0
Jul 12 03:45:51 dnsmasq-dhcp[8409]: DHCPREQUEST(br0) 192.168.50.205 f0:5c:77:b9:53:26
Jul 12 03:45:51 dnsmasq-dhcp[8409]: DHCPACK(br0) 192.168.50.205 f0:5c:77:b9:53:26 Pixel-4-XL
Jul 12 03:45:52 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:52 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:53 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc00c14f2a8 next ffffffc0110cec60 prev ffffffc0110cec60 rep_entry->list ffffffc0110cec60 next ffffffc00c14f2a8 prev ffffffc00c14f2a8
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0
Jul 12 03:45:55 kernel: protocol 0800 is buggy, dev eth0

Here is what the log file says

SSID: "Havronator"
noise: -77 dBm Channel: 7u
BSSID: FC:34:97:9C:8D:08 Capability: ESS RRM
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
Chanspec: 2.4GHz channel 5 40MHz (0x1905)
Primary channel: 7
HT Capabilities:
Supported HT MCS : 0-23 32
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11

Interference Level: Acceptable
Mode : AP Only

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
F0:5C:77:B9:53:26 Yes Yes -39dBm ac Yes Yes Yes No 2 192.5M 1M 00:27:40
9C:AE3:18:7D:EC Yes Yes -51dBm g No No No No 1 54M 54M 00:29:15
24:69:A5:45:89:48 Yes Yes -29dBm n Yes Yes No No 2 144.4M 6M 09:08:17
1 DC:4F:22:9B:F3:44 Yes Yes -51dBm n Yes Yes Yes No 1 65M 6M 00:30:16

SSID: "Havronator5G"
noise: -83 dBm Channel: 157/80
BSSID: FC:34:97:9C:8D:0C Capability: ESS RRM
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
Chanspec: 5GHz channel 155 80MHz (0xe29b)
Primary channel: 157
HT Capabilities:
Supported HT MCS : 0-31
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11

Interference Level: Acceptable
Mode : AP Only

DFS status: state IDLE time elapsed 0ms radar channel cleared by DFS none

Channel Information
----------------------------------------
Channel 36 A Band
Channel 40 A Band
Channel 44 A Band
Channel 48 A Band
Channel 52 A Band, RADAR Sensitive, Passive
Channel 56 A Band, RADAR Sensitive, Passive
Channel 60 A Band, RADAR Sensitive, Passive
Channel 64 A Band, RADAR Sensitive, Passive
Channel 100 A Band, RADAR Sensitive, Passive
Channel 104 A Band, RADAR Sensitive, Passive
Channel 108 A Band, RADAR Sensitive, Passive
Channel 112 A Band, RADAR Sensitive, Passive
Channel 116 A Band, RADAR Sensitive, Passive
Channel 132 A Band, RADAR Sensitive, Passive
Channel 136 A Band, RADAR Sensitive, Passive
Channel 140 A Band, RADAR Sensitive, Passive
Channel 149 A Band
Channel 153 A Band
Channel 157 A Band
Channel 161 A Band
Channel 165 A Band

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
38:8B:59:026:20 Yes Yes -73dBm ac No Yes Yes Yes 2 400M 6.5M 01:57:15

 

[CaptnDanLKW]

Just a thought. Have you tried to 'forget' the learned network from the client device? Also, make sure you are not using Roaming assist on the professional page when you use smart connect and/or AI Mesh.

Not sure what device you use, but assuming it's an AC and not an AX, he settings on the first page are a good start. Airtime fairness off, universal beamforming off. (Though I keep MIMO enabled)

IMHO, and my experience, it takes a little time for smart connect to settle down, but you shouldn't see outright failure of your client to associate. Might be time to reset.

 

[devnulldump]

I had very similar problem where many (not all) of my IoT bulbs constantly deauthenticate and authenticate frequently making them totally useless... I did the following on my asus AX-11000 router to keep them stay connected.

1. disable "Enable WMM APSD" [as suggested in this thread].
2. lower the "Beacon Interval" to 90 (default is 100ms)

With these, the bulbs (and google home devices as well) are pretty stable. PS: All of them are on 2.4ghz

 

[prosperot]

Disabling "Enable WMM APSD" [as suggested in this thread] solved my ATAG ONE connection problems.

The ATAG ONE would not connect to my network or would randomly disconnect without a clear reason other than these messages in my logfile: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

I never had to change this before, but since 386.8 this is apparently a needed tweak in the 2.4 wireless settings for the ATAG ONE to work. thanks!

 

[mirko991]

Disabling "Enable WMM APSD" [as suggested in this thread] solved my ATAG ONE connection problems.

The ATAG ONE would not connect to my network or would randomly disconnect without a clear reason other than these messages in my logfile: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

I never had to change this before, but since 386.8 this is apparently a needed tweak in the 2.4 wireless settings for the ATAG ONE to work. thanks!

I'm having exactly the same problem with a Wi-Fi programmable thermostat. I just tried disabling "Enable WMM APSD": hopefully good!

 

[Kewlzter]

It's definitely a setting inside the professional tab. I got frustrated and started flipping switches, and changing values, the random disconnects and station leaving errors mostly went away. After a few weeks I only see them during auto reboot, and when altering a binding.

I don't know which of the many settings helped me, and I tried to put many back to their original values, sadly I haven't a clue what most of those were.

There's many threads on the internet about this problem, no solutions. . I want you clever people to know it can be solved.