2.4Ghz devices keep disconnecting

[JoSmittyCan]

Those settings are on the 2.4GHz "Professional" tab so will only affect the 2.4GHz band even if you're using smart connect. No real loss.

The "Wireless Mode: N Only" setting is in the Wireless General tab. But you're right that it only applies to the 2.4GHz band.

I realise its a good way to check if an old 2.4Ghz device supports 802.11b/g or 802.11n. If they all still connect, that means they support "n"; And that eliminates the Enable TX Bursting setting (which only applies to b/g devices).

Jo.

 

[Ripshod]

The "Wireless Mode: N Only" setting is in the Wireless General tab. But you're right that it only applies to the 2.4GHz band.

I realise its a good way to check if an old 2.4Ghz device supports 802.11b/g or 802.11n. If they all still connect, that means they support "n"; And that eliminates the Enable TX Bursting setting (which only applies to b/g devices).

Jo.

Before you do anything you could look at the System Log>Wireless Log. You'll see the speeds your devices are connected on both band. Most, if not all your devices will be connected at 802.11n anyway.

 

[Ripshod]

i have to correct myself slightly. When Smart Connect is activated the wifi6 switch does indeed affect both bands. However, with split bands with the same SSID there's a setting for each band.

 

[JoSmittyCan]

Before you do anything you could look at the System Log>Wireless Log. You'll see the speeds your devices are connected on both band. Most, if not all your devices will be connected at 802.11n anyway.

Thanks for the hint. I didn't know about the "Wireless Log" tab yet.

Without changing anything, here's my logs on 2.4Ghz (see below). The three devices that cause problems are the Epson and Maytag(s), all of which connect using 802.11n.

Based on this, "Wireless Mode: N Only" should not help since they already are connecting with N. And disabling "TX Bursting" should only affect b/g devices.

Maybe the best thing to test is disabling "WMM APSD"? There's also disabling 802.11ax / Wifi 6 mode on 2.4 band, but I usually have no 2.4GHz device connected with 802.11ax ...

Note that the Android phone always ends-up connected to 5GHz (thanks to Smart Connect). Here I captured the 2.4GHz log before it was moved to 5GHz.

Stations List                           
----------------------------------------
idx MAC               Associated Authorized   RSSI PHY PSM SGI STBC MUBF NSS   BW Tx rate Rx rate Connect Time
    __SONOS__         Yes        Yes        -38dBm g   No  No  No   No     1  20M     54M     24M     00:02:08
    __ANDROID_PHONE__ Yes        Yes        -31dBm ax  Yes Yes Yes  No     2  20M  270.8M      6M     00:02:12
1   __EPSON__         Yes        Yes        -37dBm n   Yes Yes No   No     1  20M   72.2M   72.2M     00:02:13
2   __MAYTAG_A__      Yes        Yes        -41dBm n   Yes Yes Yes  No     1  20M     65M      6M     00:01:55
2   __MAYTAG_B__      Yes        Yes        -38dBm n   Yes Yes Yes  No     1  20M     65M      6M     00:01:55

Jo.

 

[JoSmittyCan]

i have to correct myself slightly. When Smart Connect is activated the wifi6 switch does indeed affect both bands. However, with split bands with the same SSID there's a setting for each band.

I tried disabling Smart Connect for a test and that works almost as well. Instead of the router requesting the devices to change band, we rely solely on the device's own algorithm to decide on the best band to select. Most of my devices end-up on the same band as with Smart Connect, except for one laptop with an Intel AX200 wifi adapter which seems to be happy with the 2.4Ghz band by default.

For now I kept Smart Connect enabled. Need to figure out what setting to try next. The disconnection problem usually takes 12+ hours to occur after a router reset, so that takes time!

I see people in other threads who had troubles after disabling "WMM APSD". Maybe not a good idea. So I guess the next step is to try disabling 802.11ax / Wifi 6 mode on 2.4GHz, as originally suggested ...

Jo.

 

[follower]

I tried disabling Smart Connect for a test and that works almost as well. Instead of the router requesting the devices to change band, we rely solely on the device's own algorithm to decide on the best band to select. Most of my devices end-up on the same band as with Smart Connect, except for one laptop with an Intel AX200 wifi adapter which seems to be happy with the 2.4Ghz band by default.

For now I kept Smart Connect enabled. Need to figure out what setting to try next. The disconnection problem usually takes 12+ hours to occur after a router reset, so that takes time!

I see people in other threads who had troubles after disabling "WMM APSD". Maybe not a good idea. So I guess the next step is to try disabling 802.11ax / Wifi 6 mode on 2.4GHz, as originally suggested ...

Jo.

Enabling WMM APSD makes a lot of issues. It makes unknown disconnection issue a lot. I've read all of your replies above. I think you believe what you believe and want to do what you want to do. I give up.

 

[OzarkEdge]

Need to figure out what setting to try next.
So I guess the next step is to try disabling 802.11ax / Wifi 6 mode on 2.4GHz, as originally suggested ...

Jo.

You don't sound very serious about solving your crappy IoT client connection issue. I suggest you leave the washing machine off your network and stop wasting time... your laundry will never notice.

OE

 

[OzarkEdge]

These connection problems have been there this since I install that router, yes.

I schedule a reboot to make sure I recover from power outages. When that happens (for long enough), both my modem and router eventually lose power. And when power comes back, sometimes the router is quicker than the modem to boot and it will never get a valid IP address. That's what was happening with my previous router (DD-WRT) -- never tried it yet with the Asus router.

On DD-WRT, I had a watchdog setup. The router would ping (every few minutes) a couple of reliable IP addresses (Google, etc.) and if none of them ever respond, it would force a reboot of the router. This option is not available on Asus routers, so I just schedule a reboot in middle of the night.

Note that maybe the Asus router is more robust than DD-WRT regarding this issue. I just never tested it, so I setup the scheduled reboot.

Jo.

I would install a UPS and stop rebooting my router needlessly.

OE

 

[Tech9]

crappy IoT client

This is exactly what I use the Wi-Fi capabilities of my appliances - useless IoT test client. I've noticed Wi-Fi doesn't load the washer and doesn't move the clothes to the dryer even with perfect -40dBm connection. Perhaps my router settings were not right or Alexa was on holidays during my tests.

 

[OzarkEdge]

Give me an IoT client that will fold and put away laundry and I'm all in!

OE

 

[Tech9]

For this you had to choose the right hardware and perhaps adjust some settings years ago. If it's not working now - too late.

 

[JoSmittyCan]

You don't sound very serious about solving your crappy IoT client connection issue. I suggest you leave the washing machine off your network and stop wasting time... your laundry will never notice.

OE

Why would you say that? There's something wrong that I want to solve. This impacts my Epson printer as well.

I setup a syslog server and I'm monitoring to see if I can catch an unusual log message before the problem starts. Meanwhile, I disabled 802.11ax on 2.4GHz.

Any other idea is welcome.

 

[Tech9]

I have posted some better compatibility settings of AX router some time ago here:

AX86U Check my settings please

Can anyone chime in on these settings AX86U Merlin 388.1_0

www.snbforums.com

Look at your Wi-Fi connected printer as an IoT device.

Please, don't ask me what and why about specific settings. Take it or leave it deal.

 

[JoSmittyCan]

Please, don't ask me what and why about specific settings. Take it or leave it deal.

I would never dare.

 

[userforum]

Hi, I also have this problem of multiple devices disconnecting. I have an updated to the last fw 3000 v2 router. Any idea?.

Jan 3 08:14:30 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Disassociated due to inactivity (4), rssi:-65
Jan 3 08:14:31 kernel: wl0: random key value: 08E1D35B6D6CCD00262F0333CDEAFB0670125341F3B9066818CF41DCD3AD2C51
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Unspecified reason (1), rssi:0
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(685): eth5: Auth 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(722): eth5: Assoc 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:44 kernel: wl0: random key value: 2DB80134056F7AEC162502CDF88D3A44015996A4B63F0FA1F82F6751AE386214
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Unspecified reason (1), rssi:-65
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(685): eth5: Auth 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(722): eth5: Assoc 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 09:23:23 wlceventd: wlceventd_proc_event(685): eth5: Auth CE:03:8A:8F:92:FE, status: Successful (0), rssi:0
Jan 3 09:23:23 wlceventd: wlceventd_proc_event(722): eth5: Assoc CE:03:8A:8F:92:FE, status: Successful (0), rssi:-75
Jan 3 09:57:21 kernel: wl1: random key value: 10F84CA3B454954875320387DC2C86FB598340D43D300D844B4970BE27001FA6
Jan 3 09:57:21 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind B0:3CC:FB:79:BC, status: 0, reason: Unspecified reason (1), rssi:0
Jan 3 09:57:21 wlceventd: wlceventd_proc_event(662): eth6: Disassoc B0:3CC:FB:79:BC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 3 10:00:31 wlceventd: wlceventd_proc_event(685): eth6: Auth B0:3CC:FB:79:BC, status: Successful (0), rssi:0
Jan 3 10:00:31 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc B0:3CC:FB:79:BC, status: Successful (0), rssi:-63
Jan 3 10:11:17 kernel: wl0: random key value: 0FB383970610C5A9199A03B3619E1979430F92A82A6201CA2FBE8B988CADB820
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind C4:5B:BE:78:54:82, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(662): eth5: Disassoc C4:5B:BE:78:54:82, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(685): eth5: Auth C4:5B:BE:78:54:82, status: Successful (0), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(722): eth5: Assoc C4:5B:BE:78:54:82, status: Successful (0), rssi:-63

 

[JoSmittyCan]

Hi, I also have this problem of multiple devices disconnecting. I have an updated to the last fw 3000 v2 router. Any idea?.

Jan 3 08:14:30 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Disassociated due to inactivity (4), rssi:-65
Jan 3 08:14:31 kernel: wl0: random key value: 08E1D35B6D6CCD00262F0333CDEAFB0670125341F3B9066818CF41DCD3AD2C51
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Unspecified reason (1), rssi:0
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(685): eth5: Auth 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:31 wlceventd: wlceventd_proc_event(722): eth5: Assoc 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:44 kernel: wl0: random key value: 2DB80134056F7AEC162502CDF88D3A44015996A4B63F0FA1F82F6751AE386214
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind 2C:2B:F9:8AC:43, status: 0, reason: Unspecified reason (1), rssi:-65
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(685): eth5: Auth 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 08:14:44 wlceventd: wlceventd_proc_event(722): eth5: Assoc 2C:2B:F9:8AC:43, status: Successful (0), rssi:-65
Jan 3 09:23:23 wlceventd: wlceventd_proc_event(685): eth5: Auth CE:03:8A:8F:92:FE, status: Successful (0), rssi:0
Jan 3 09:23:23 wlceventd: wlceventd_proc_event(722): eth5: Assoc CE:03:8A:8F:92:FE, status: Successful (0), rssi:-75
Jan 3 09:57:21 kernel: wl1: random key value: 10F84CA3B454954875320387DC2C86FB598340D43D300D844B4970BE27001FA6
Jan 3 09:57:21 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind B0:3CC:FB:79:BC, status: 0, reason: Unspecified reason (1), rssi:0
Jan 3 09:57:21 wlceventd: wlceventd_proc_event(662): eth6: Disassoc B0:3CC:FB:79:BC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 3 10:00:31 wlceventd: wlceventd_proc_event(685): eth6: Auth B0:3CC:FB:79:BC, status: Successful (0), rssi:0
Jan 3 10:00:31 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc B0:3CC:FB:79:BC, status: Successful (0), rssi:-63
Jan 3 10:11:17 kernel: wl0: random key value: 0FB383970610C5A9199A03B3619E1979430F92A82A6201CA2FBE8B988CADB820
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(645): eth5: Deauth_ind C4:5B:BE:78:54:82, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(662): eth5: Disassoc C4:5B:BE:78:54:82, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(685): eth5: Auth C4:5B:BE:78:54:82, status: Successful (0), rssi:0
Jan 3 10:11:17 wlceventd: wlceventd_proc_event(722): eth5: Assoc C4:5B:BE:78:54:82, status: Successful (0), rssi:-63

Looking at these logs, the event @08:14:30 (that repeats again @08:14:44) could be similar to my problem. I see this is an LG appliance, so probably on 2.4GHz. The last event is also suspect (@10:11:17) -- An Espressif wifi chip, so probably an IoT (smart bulb, etc.), so also 2.4GHz I suppose.

At the same time, with a RSSI of -65, signal is not very strong and you could be in the territory of the Smart Connect rules or Roaming Assistant feature (depending how you're setup). In my case, when Smart Connect triggers, I see an explicit log from the router asking for the band change, which we don't see here, however.

In my case, when this problem occurs, I see the "Access Time" in the Network Map that always resets to 00:00:00 every 15-20 seconds for the faulty 2.4GHz devices. Maybe check if that's what you get as well.

In any case, please provide more information on the devices, the bands they use and wifi settings. Otherwise it's too much speculation.

 

[JoSmittyCan]

Well, it's now been 57+ hours since I rebooted the router after disabling 802.11ax on 2.4GHz and the problem did not reoccur. I'm not 100% sure, but it's never been "stable" for that long, so I have to assume that the problem is solved.

Note that I first tried disabling 802.11ax on 2.4GHz *without* rebooting but the problem reoccurred a few hours later. It's only after I rebooted (the router) that it worked -- So apparently a reboot is required after changing this setting.

Side effect is that AX devices that connect to 2.4GHz no longer benefit from wifi 6's faster speeds. It's like 802.11ac for them (!). In my case, I don't have many high speed clients, so I put them all on the 5GHz band (that still supports wifi 6).

Now, ... I may continue testing to see if other less intrusive settings can also solve the problem, such as disabling IGMP Snooping, disabling TX Bursting, disabling WMM APSD, disabling Multi-user MMO and disabling Explicit Beamforming. -- Any comment on these settings regarding potential problems with legacy 802.11n 2.4GHz IoT devices is appreciated.

Jo.

 

[Tech9]

Almost guaranteed none of this is supported by your IoT devices on 2.4GHz, most of it was never supported in 802.11n on 2.4GHz, some of it was on paper only years ago, but never implement by any manufacturer. Asus exposes too many settings and Asuswrt has no dependencies*. This is only causing confusion in home users with less knowledge - the main product target market.

* - 2.4GHz Legacy (802.11b/g) with MU-MIMO Enabled is a valid setting in Asuswrt although not possible. In a properly built user-friendly firmware selecting one option has to disable/remove whatever doesn't apply anymore with the selection. In some cases like enabling MU-MIMO also enables Explicit Beamforming automatically it acts properly, but for most settings Asuswrt is mostly "blind".

 

[JoSmittyCan]

After some research, it seems common for 2.4GHz IoT devices to have problems with the 802.11ax protocols. I find similar issues on the TP-Link and Linksys forums.

Asus basically says it straight that 802.11ax must be disabled (on 2.4GHz bans) for IoT device compatibility. From what I understand, RTS/CTS handshaking is required for 802.11ax backward compatibility with pre-802.11ax devices ; And some IoT devices simply don't support RTS/CTS or don't support it properly. So the solution is to disable 802.11ax.

Bummer ...

Jo.

Ref: https://www.asus.com/support/FAQ/1042475/

 

[glens]

I think that's gotta be wrong in some respect. If the feature is required for backward compatibility, and the devices don't like the feature, that means they're not backward compatible, which means they're /forward/ compatible, which means they're AX, which means they're fine with it? See the circularity of the logic? Can't guess which part is wrong, but something must be... : - )