384.14_2 on AC86U | Disassociated because sending station is leaving...

[DarkWolfSLV]

A little update: still having troubles with v384.13 - all my devices are experiencing short disconnections, I can even match my phone and router logs when it happens which discards this to be a cosmetic issue.

 

[DarkWolfSLV]

Update #2: I found this discussion where RMerlin suggests to disable a few settings which I did for 2.4ghz and 5ghz.

- Disable Universal/Implicit Beamforming (Explicit is fine)
- Disable Airtime Fairness
- Disable MU-MIMO

After 1h still having drops
Is there a way on the CLI where I can get more detailed logs to try to figure out why it is doing it?
I'm even considering moving back to stock firmware to test, but I do not want to lose Diversion and Skynet.

 

[DarkKnight75]

Update #2: I found this discussion where RMerlin suggests to disable a few settings which I did for 2.4ghz and 5ghz.

- Disable Universal/Implicit Beamforming (Explicit is fine)
- Disable Airtime Fairness
- Disable MU-MIMO

After 1h still having drops
Is there a way on the CLI where I can get more detailed logs to try to figure out why it is doing it?
I'm even considering moving back to stock firmware to test, but I do not want to lose Diversion and Skynet.

Did you do a full reset of router? Restore/Initialize?

 

[DarkWolfSLV]

Did you do a full reset of router? Restore/Initialize?

I did a reboot, not a factory reset on the router. As you can see on the logs, the reboot happened around 10am and 2h later I still have good amount of WLCEVENTD.

I do not see why a factory reset will make a difference.
Thanks.

 

[ColinTaylor]

I did a reboot, not a factory reset on the router. As you can see on the logs, the reboot happened around 10am and 2h later I still have good amount of WLCEVENTD.

If you trace the progress of an individual MAC address through the log the entries make more sense. Pay close attention to the timestamps as certain events do not necessarily appear in sequential order in the log if they happen at almost the same time.

You will see that the clients are by preference connecting to the 5GHz radio. There are 5 times in that 2 hour log file where the 5GHz radio decides to change its channel. When it does this the 5GHz clients are disconnected forcing them to connect to the 2.4GHz radio. After the new 5GHz channel becomes available and a suitable period of time has passed the clients reconnect to the 5GHz radio. This process repeats every time the 5GHz radio changes channel.

So the obvious thing to try is to assign the 5GHz radio to a fixed non-DFS channel and see what happens.

 

[Maverickcdn]

Im starting to wonder if Asus didnt leave this debugging (WLCEVENTD) there on purpose so people could diagnose issues with wireless clients better??

Anyone else feel the same way?

 

[dave14305]

Im starting to wonder if Asus didnt leave this debugging (WLCEVENTD) there on purpose so people could diagnose issues with wireless clients better??

Anyone else feel the same way?

Yes. People are upset these messages are in their syslog, but then they can be more upset when Asus can't diagnose wireless issues with their firmware. I think their mistake is the loglevel that these messages appear.

 

[DarkWolfSLV]

I do have Smart Connect enabled.
Taking into consideration Maverickcdn's comments, could you consider these events "normal" due to the nature of Smart Connect? It has not been so long to confirm if all my nodes are experiencing *drops* because of this.

All my devices should be capable of 802.11n - do you have any suggestion if case I disable Smart Connect?

 

[ColinTaylor]

I do have Smart Connect enabled.
Taking into consideration Maverickcdn's comments, could you consider these events "normal" due to the nature of Smart Connect? It has not been so long to confirm if all my nodes are experiencing *drops* because of this.

All my devices should be capable of 802.11n - do you have any suggestion if case I disable Smart Connect?

The issue I was referring to in post #34 was not Smart Connect, it was the setting for the Control Channel:



I've never used AiMesh so I don't know whether that limits what options you have available.

 

[DarkKnight75]

I did a reboot, not a factory reset on the router. As you can see on the logs, the reboot happened around 10am and 2h later I still have good amount of WLCEVENTD.

I do not see why a factory reset will make a difference.
Thanks.

There are plenty of threads on this, which you can find here. Anytime i upgrade or downgrade firmware, i do a full restore/initialize and re-configure manually. There may

Yes. People are upset these messages are in their syslog, but then they can be more upset when Asus can't diagnose wireless issues with their firmware. I think their mistake is the loglevel that these messages appear.

Why is that these messages don't appear on 384 12 or .13 on my ac86u anyways? As soon as these messages creep up on my router clients lost connection and reconnected after 5 10 seconds. Definitely not right IMO

 

[Maverickcdn]

Why is that these messages don't appear on 384 12 or .13 on my ac86u anyways? As soon as these messages creep up on my router clients lost connection and reconnected after 5 10 seconds. Definitely not right IMO

https://www.asuswrt-merlin.net/changelog-382
384.14 (14-Dec-2019)
- UPDATED: RT-AX88U to GPL 384_6436 (with Let's Encrypt fixes
backported from 384_81351)
- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351
- UPDATED: RT-AC88U, RT-AC3100 to GPL 384_81351 and binary
blobs from 384_81116
- UPDATED: RT-AC5300 to GPL 384_81351 and binary blobs from
384_81219.

If I'm not mistaken it showed up here. The WLCEVENTD messages anyway

 

[DarkWolfSLV]

After some reading I came up with the below configuration. Once I set the Channel bandwidth and Control Channel to one, and only one value the WLCEVENTD went away and with that the disconnections.
I tried leaving the Channel bandwidth dynamic (20/40 MHz) while changing Control Channel from auto to "X" and still got problems, but once I got the below settings the errors disappeared.


Could this be a bad/aggressive implementation of Smart Connect or Channel optimization??

 

[automaton]

After some reading I came up with the below configuration. Once I set the Channel bandwidth and Control Channel to one, and only one value the WLCEVENTD went away and with that the disconnections.
I tried leaving the Channel bandwidth dynamic (20/40 MHz) while changing Control Channel from auto to "X" and still got problems, but once I got the below settings the errors disappeared.


Could this be a bad/aggressive implementation of Smart Connect or Channel optimization??

View attachment 21312

Just wanted to say thanks. I have a AC68U combined with a TP-LINK AC1200 repeater, and originally I had it on Merlin 384.13_0 which did not have this problem, but it did have another problem where the web UI (and SSH) would become unresponsive after a week+ of operation (but the router continued to work).

I then upgraded to 384.15_0 hoping it would fix it, which it did, but then I started getting massive spam in the log about disassoc mostly from one of my Android devices.

I first tried disabling Airtime Fairness and Universal Beamforming on 2.4GHz which helped partially but not fully, and after that I found your post and set mine the same as yours. Since then I only get it a few times a day when I am walking between areas where the phone might switch WiFi hotspots, but that's it.

This problem definitely appeared betwen v13 and v15, and it's pretty annoying. Thanks for the help.

 

[d3f]

so i was using a gt5300 for a while now but needed to switch back to my old ac88u because i got ATT fiber now and i want to try and use my asus router direct to the ont and remove the att modem. this requires merlin fw also. so i flashed the latest 384.17 on my ac88u and have done like 10 restore/intilize, couple of hold the button on the back of the router resets.. ive tried all the settings in this thread but i still can not get rid of these same errors , and the wifi resetting its self... after reading this thread i downgraded to 384.13 and have no issues at all its rock solid... has anyone been able to find out the cause ?

i turned down tx power and thought that might of helped but didnt really, someone mentioned google minis, i have like 5 atleast and a google home and home hub. but also my harmony was getting same message "dissassociated because ....." but like i said i go back to 384.13 no issues.

 

[d3f]

wish i kept the log, my router was literally stroking out with errors and i was droping wifi connections with my laptop .. untell i went back to 384.13 now its solid

 

[RAH-66]

I have a similar problem with PCE-AC88 and AX88U on the channels 36-48

May 18 23:27:46 wlceventd: wlceventd_proc_event(499): eth7: Auth 34:97:F6:B6:FF:FA, status: Successful (0)
May 18 23:27:46 wlceventd: wlceventd_proc_event(527): eth7: Assoc 34:97:F6:B6:FF:FA, status: Successful (0)
May 18 23:32:52 wlceventd: wlceventd_proc_event(481): eth7: Disassoc 34:97:F6:B6:FF:FA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
May 18 23:32:52 wlceventd: wlceventd_proc_event(481): eth7: Disassoc 34:97:F6:B6:FF:FA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

On the channels 52-161 and 20/40/80/160Mhz works fine. Enabling and disabling the functions of AX, MU-MIMO, Beamforming and etc. does not affect. It turned out that the adapter does not see wifi net with channel 40 / 20 MHz. Because of this, 36+40 / 40 MHz and 36+40+44+48 / 80 MHz do not work

 

[Pitchounet]

Same problem on my AC88U which is deconnecting reconneting me all the time...with the same entries in the log...

 

[Pitchounet]

What’s your setup like? Do you have more that one access point?

No, only one.

 

[macaroon]

I'm seeing this too ... it got real bad today (after router was power cycled). Running 384.17 on a AC68U. Has anyone tried 384.18? I was thinking to give it a go but if it didn't work my next step would be to go back to 3.84.13 which looks like it might be a pain if I updated to 3.84.18 already.

# grep "d11 RC reserved" user | cut -d":" -f1 | grep -oP "^[0-9\x2D]+" | sort | uniq -c
6 2020-04-11
170 2020-04-12
252 2020-04-13
293 2020-04-14
244 2020-04-15
359 2020-04-16
444 2020-04-17
176 2020-04-18
136 2020-04-19
110 2020-04-20
435 2020-04-21
903 2020-04-22
288 2020-04-23
653 2020-04-24
349 2020-04-25
635 2020-04-26
677 2020-04-27
603 2020-04-28
726 2020-04-29
450 2020-04-30
352 2020-05-01
203 2020-05-02
143 2020-05-03
120 2020-05-04
231 2020-05-05
360 2020-05-06
307 2020-05-07
322 2020-05-08
243 2020-05-09
24 2020-05-10
227 2020-05-22
407 2020-05-23
383 2020-05-24
348 2020-05-25
335 2020-05-26
357 2020-05-27
340 2020-05-28
405 2020-05-29
364 2020-05-30
202 2020-05-31
381 2020-06-01
384 2020-06-02
283 2020-06-03
497 2020-06-04
550 2020-06-05
358 2020-06-06
327 2020-06-07
305 2020-06-08
349 2020-06-09
415 2020-06-10
330 2020-06-11
442 2020-06-12
317 2020-06-13
248 2020-06-14
450 2020-06-15
257 2020-06-16
327 2020-06-17
346 2020-06-18
514 2020-06-19
294 2020-06-20
232 2020-06-21
881 2020-06-22
278 2020-06-23
571 2020-06-24
420 2020-06-25
428 2020-06-26
353 2020-06-27
88 2020-06-28
326 2020-06-29
269 2020-06-30
399 2020-07-01
373 2020-07-02
302 2020-07-03
253 2020-07-04
196 2020-07-05
347 2020-07-06
273 2020-07-07
324 2020-07-08
410 2020-07-09
208 2020-07-10
238 2020-07-11
115 2020-07-12
237 2020-07-13
230 2020-07-14
332 2020-07-15
208 2020-07-16
125 2020-07-17
2 2020-07-18
10 2020-07-19
195 2020-07-20
217 2020-07-21
294 2020-07-22
210 2020-07-23
228 2020-07-24
222 2020-07-25
208 2020-07-26
1611 2020-07-27

Cheers,

 

[Mr.H]

Hey, for anybody whom it might help in the future. I managed to track down this issue to TLS version mismatch issue on my RT-AC68U, 384.19.
So, when turning debug/all logging on the router, I saw log like below (see log at the bottom of the message).
When I used tcpdump to sniff on br0 - saw pretty much the same stuff, but in more networkish way.
When I tcpdumped eth1, as stated in the log, I saw that my device tries to establish TLS 1.1 connection with the server:

Handshake Type: Client Hello (1)
Version: TLS 1.1 (0x0302)

And seems like server has only TLS v1.2 available starting from 2 weeks ago:

Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Alert Message
Level: Fatal (2)
Description: Protocol Version (70)

So, I contacted company to fix this or send firmware update to struggling customers)

Jun 22 13:25:23 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth xx:xx:xx:xx:xx:xx, status: Successful (0)
Jun 22 13:25:23 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc xx:xx:xx:xx:xx:xx, status: Successful (0)
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 available DHCP range: 192.168.xxx.xxx -- 192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 tags: lan, xx:xx:xx:xx:xx:xx, known, br0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 DHCPOFFER(br0) 192.168.xxx.xxx xx:xx:xx:xx:xx:xx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 bootfile name: lpxelinux.0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 next server: 192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  1 option: 53 message-type  2
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option: 54 server-identifier  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option: 51 lease-time  1d
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option: 58 T1  12h
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option: 59 T2  21h
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option:  1 netmask  255.255.255.0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option: 28 broadcast  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option:  6 dns-server  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338817 sent size:  4 option:  3 router  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 available DHCP range: 192.168.xxx.xxx -- 192.168.xxx.xxx00
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 DHCPREQUEST(br0) 192.168.xxx.xxx xx:xx:xx:xx:xx:xx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 tags: lan, xx:xx:xx:xx:xx:xx, known, br0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 DHCPACK(br0) 192.168.xxx.xxx xx:xx:xx:xx:xx:xx BlipBP
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 bootfile name: lpxelinux.0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 next server: 192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  1 option: 53 message-type  5
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option: 54 server-identifier  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option: 51 lease-time  1d
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option: 58 T1  12h
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option: 59 T2  21h
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option:  1 netmask  255.255.255.0
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option: 28 broadcast  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option:  6 dns-server  192.168.xxx.xxx
Jun 22 13:25:23 dnsmasq-dhcp[1293]: 2882338818 sent size:  4 option:  3 router  192.168.xxx.xxx
Jun 22 13:25:24 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc xx:xx:xx:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)