What's new
  • 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!

Roaming Assist and Constant Deauth/Reassoc Question

5150

New Around Here
Hi everyone, I have a device that I'm getting hundreds of disconnects/re-associations in the log file every day. I have around 50 devices on my network, and this is the only device that constantly disconnects and reconnects like this. I don't ever recall enabling Roaming Assist in my XT8 but it's enabled on all 3 bands.

I was wondering if I should try disabling Roaming Assist for my 2.4 band to see if it helps the problem? If I'd do so, would that then disable the ability for other wireless devices (like our cell phones for example) to move from node to node in my network? I have a 3 node network including the main router. Width is set to 20 for my 2.4 network and Smart Connect is also off. Read Roaming Assist might cause something like this so wanted to pose the question here.

This device in question is a Ring Bridge, used to control my smart lighting. I have it bound to the main router so it can't connect to anything else. I've also tried moving it closer to the main router too but I still got the same amount of disconnects. This is not actually causing an issue at the moment. However I recently had a major problem with the Ring Bridge and I'm not sure if it was caused by these disconnects, OR, if these frequent disconnects are the symptom of a problematic Ring Bridge.

Apr 18 01:05:10 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind ------------, status: 0, reason: Unspecified reason (1), rssi:0
Apr 18 01:05:10 wlceventd: wlceventd_proc_event(685): eth4: Auth --------------- status: Successful (0), rssi:0
Apr 18 01:05:11 wlceventd: wlceventd_proc_event(695): eth4: ReAssoc -----------, status: Successful (0), rssi:-55

Thanks in advance!
 
Like many other IoT devices your Ring Bridge connects only to the 2.4 GHz band. I would not bind it to the router. Let the clients choose where they want to connect. I would set the 2.4 GHz to 20 MHz, Auto channel and use just WPA2-Personal. If you feel that you need to have WPA2/WPA3-Personal set up a guest WIFI on the 2.4 GHz band for your IoT devices with just WPA2-Personal.
 
This Auto channel advice can be very disruptive for IoT devices. I would say to stabilize problematic IoT do this - Smart Connect off, fixed 2.4GHz channel, 20MHz only, N-Only, WPA2-Personal only, PMF disabled, Key Rotation Interval to 0, all beamforming off, APSD off, Preamble Type to Long and in addition DHCP lease time at least 86400 sometimes helps. Some IoT devices also don't like DNS encryption, interception, redirection and filtering upstream.
 
Thank you both for the replies!

I do have my 2.4 channel locked to channel 11, and only using WPA2 Personal.

My settings do actually match most of the above recommendations. Differences are my key rotation is set to 3600 and Beamforming is on. I actually had problems specifically with this Ring Bridge the last time I disabled beamforming. APSD is also enabled.

I'm going to start with one change at time and see if it helps, starting with unbinding the Ring Bridge from the main router.

Sounds like disabling Roaming Assist is def not the answer.

Again, appreciate the replies!
 
There is no Explicit Beamforming on 802.11n and what Asus calls Universal Beamforming is a non-standard Broadcom attempt to do beamforming without client support or interaction, known to cause issues. You also don't want APSD for IoT devices and Preamble Type Long is the default, may stabilize devices at the edges of coverage area. Careful with Asus default settings because Asuswrt has very limited dependencies and some settings make no sense whatsoever. Make sure this Roaming Assist is actually doing something, I found it non-working in quite a few firmware versions for different Asus routers.
 
There is no Explicit Beamforming on 802.11n and what Asus calls Universal Beamforming is a non-standard Broadcom attempt to do beamforming without client support or interaction, known to cause issues. You also don't want APSD for IoT devices and Preamble Type Long is the default, may stabilize devices at the edges of coverage area. Careful with Asus default settings because Asuswrt has very limited dependencies and some settings make no sense whatsoever. Make sure this Roaming Assist is actually doing something, I found it non-working in quite a few firmware versions for different Asus routers.

I think this goes back to a lot of legacy around AsusWRT Perhaps... nobody is perfect, and Broadcom, like other chipset vendors, has bugs - some are fixed, some are still broken.

1) there actually is explicit beamforming in 802.11n, but not a commonly agreed format/implementation, and there is also the implicit beamforming as well, but this is very proprietary.. the guidance here to disable all beamforming for legacy is good - solves a lot of problems

2) ASPD - many vendors call this U-ASPD, this is part of 802.11e (and WFA WMM), and it's basically pretty safe to keep enabled for most devices

Not sure what folks target this one - it's very mature, most AP's and clients have this enabled by default because of WMM, and WMM is needed for 11n and beyond.

3) Preamble - I'd advise to keep this short, as long only support very old 802.11b devices - and if you force long preambles, then all management messages are at legacy 11b 1Mbps rates - not good...

4) Airtime Fairness - this shouldn't matter, but some of the Broadcom SDK's have issues here for some unknown reason (unknown, as it's not logged usually, even on Hardware SDK's) - so for some, depending on a lot of variables, might consider togging it from default and see where it goes...

FWIW - I've looked at both QCA and MTK boards, and AT fairness isn't an issue with them - with BCM, it's an issue, and likely a bug...
 
if you force long preambles, then all management messages are at legacy 11b 1Mbps rates - not good...

Definitely not good for speed, but helps with range and may eventually stabilize IoT devices around the edges of coverage area. Tested, working okay on Broadcom hardware. This 2.4GHz band is mostly used for IoT these days, worth to try. Asus default is Long.
 
@Tech9 - 2.4, properly configured...

2.4 isn't a wasteland - 11ax on a 20MHz channel on 2*2:2 radios can easily do 200 Mbps... Also look at DTIM values - for WMM/ASPD - 3 is a good place to land for most devices...

Might note that we've killed off 11b, and removed the bogus VHT...

Code:
    capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
    signal: -21.00 dBm
    last seen: 571 ms ago
    Information elements from Probe Response frame:
    SSID: thumper
    Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
    DS Parameter set: channel 11
    Country: US    Environment: Indoor/Outdoor
        Channels [1 - 11] @ 30 dBm
    ERP: <no flags>
    RSN:     * Version: 1
         * Group cipher: CCMP
         * Pairwise ciphers: CCMP
         * Authentication suites: PSK
         * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
    BSS Load:
         * station count: 1
         * channel utilisation: 77/255
         * available admission capacity: 0 [*32us]
    Supported operating classes:
         * current operating class: 81
    HT capabilities:
        Capabilities: 0x11ed
            RX LDPC
            HT20
            SM Power Save disabled
            RX HT20 SGI
            RX HT40 SGI
            TX STBC
            RX STBC 1-stream
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: No restriction (0x00)
        HT TX/RX MCS rate indexes supported: 0-15
    HT operation:
         * primary channel: 11
         * secondary channel offset: no secondary
         * STA channel width: 20 MHz
         * RIFS: 0
         * HT protection: no
         * non-GF present: 1
         * OBSS non-GF present: 0
         * dual beacon: 0
         * dual CTS protection: 0
         * STBC beacon: 0
         * L-SIG TXOP Prot: 0
         * PCO active: 0
         * PCO phase: 0
    Extended capabilities:
         * Extended Channel Switching
         * QoS Map
         * UTF-8 SSID
         * Operating Mode Notification
         * 6
    HE capabilities:
        HE MAC Capabilities (0x000d9a081040):
            +HTC HE Supported
            TWT Responder
            Dynamic BA Fragementation Level: 1
            BSR
            OM Control
            Maximum A-MPDU Length Exponent: 3
            RX Control Frame to MultiBSS
            A-MSDU in A-MPDU
            OM Control UL MU Data Disable RX
        HE PHY Capabilities: (0x02700c881fc18304112c00):
            HE40/2.4GHz
            Device Class: 1
            LDPC Coding in Payload
            HE SU PPDU with 1x HE-LTF and 0.8us GI
            STBC Tx <= 80MHz
            STBC Rx <= 80MHz
            DCM Max Constellation Rx: 1
            SU Beamformer
            SU Beamformee
            MU Beamformer
            Beamformee STS <= 80Mhz: 7
            Sounding Dimensions <= 80Mhz: 1
            Ng = 16 SU Feedback
            Ng = 16 MU Feedback
            Codebook Size SU Feedback
            Codebook Size MU Feedback
            PPE Threshold Present
            HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
            HE ER SU PPDU 4x HE-LTF 0.8us GI
            HE ER SU PPDU 1x HE-LTF 0.8us GI
            TX 1024-QAM
            RX 1024-QAM
            RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
        HE RX MCS and NSS set <= 80 MHz
            1 streams: MCS 0-11
            2 streams: MCS 0-11
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        HE TX MCS and NSS set <= 80 MHz
            1 streams: MCS 0-11
            2 streams: MCS 0-11
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        PPE Threshold 0x1b 0x1c 0xc7 0x71 0x1c 0xc7 0x71
    WMM:     * Parameter version 1
         * u-APSD
         * BE: CW 15-1023, AIFSN 3
         * BK: CW 15-1023, AIFSN 7
         * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
         * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

My config there...

Code:
config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc@0/c000000.wifi+1'
        option band '2g'
        option channel '11'
        option htmode 'HE20'
        option txpower '23'
        option country 'US'
        option cell_density '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'thumper'
        option encryption 'psk2+ccmp'
        option dtim_period '3'
        option key 'password'
        option wpa_disable_eapol_key_retries '1'

Kind of keeping it simple...
 
Last edited:
This Auto channel advice can be very disruptive for IoT devices. I would say to stabilize problematic IoT do this - Smart Connect off, fixed 2.4GHz channel, 20MHz only, N-Only, WPA2-Personal only, PMF disabled, Key Rotation Interval to 0, all beamforming off, APSD off, Preamble Type to Long and in addition DHCP lease time at least 86400 sometimes helps. Some IoT devices also don't like DNS encryption, interception, redirection and filtering upstream.

Just to follow up... you've done a lot of legacy guidance, but consider below...

1) Smart Connect - whatever, as mentioned, shouldn't be a problem with single band devices

2) 2.4GHz - wise to do 20MHz channels - not just because of interference, narrow channels buy one range as a 3dB improvement on the link budget, and most IoT devices are 20MHz only on 2.4 (and many now on 5GHz)

3) WPA2-Personal - good place to land for compat, but WPA2/WPA3-mixed is something looking forward

4) PMF - for WPA2, disable it, for WPA3, keep it optional

5) Key Rotation - this is for the WPA keys - keep this short, as this involves all clients, I keep mine at the moment at 3600 seconds - this is not just the key rotation for the client key, but also the group key

6) DHCP Leases - I keep my leases at 2 hours for most - 7200 seconds - keep in mind that most clients will start checking in for a lease update 1/2 times lease time...

7) DNS - on the LAN side, it shouldn't matter if the router is configured for the WAN side doing DoT/DoH/whatever, on the LAN side DNS is usually just that for most routers..

Get into AsusWRT scripting solutions, well, all bets are off there, who knows what they're cooking up...
 
And a lot of this is around client polling for 802.11r - the default here is actually around 300 seconds before a client is assumed to be disassociated, but also, this can be client driven, e.g the client is leaving to save power...

One thing that can help is drop the GTK rating down to the polling interval (or bump the polling interval up to the GTK value)

Some folks have mentioned Roaming Assistant - and that's ok, but if one is single band, it really doesn't matter, as in a BHR scenario, there's only the one radio - gets a bit more complicated with some mesh implementations, but even there, the disconnect/re-associate is a device ping-ponging across the different MeshPoints and/or AP's...
 
Agree to what you are saying for keeping it simple and different settings, but Asus has some quirks. Broadcom version of Smart Connect is not the best, Roaming Assist is often broken, users found WPA2/WPA3 mixed broken for some models in later firmware... what I suggested above is not what it should be in theory, but what may work for this specific device. Otherwise I also run single SSID, short DHCP lease time, 3600 key rotation, etc... but on different hardware.
 
Agree to what you are saying for keeping it simple and different settings, but Asus has some quirks. Broadcom version of Smart Connect is not the best, Roaming Assist is often broken, users found WPA2/WPA3 mixed broken for some models in later firmware..

perhaps time to consider other vendors that do it right

:D
 
If you ask me I would avoid Broadcom in general and strongly believe even MediaTek has now better driver support and compatibility. Many folks around may disagree, but this is my experience. For mesh systems - Qualcomm. You know the inner workings better.
 
If you ask me I would avoid Broadcom in general and strongly believe even MediaTek has now better driver support and compatibility. Many folks around may disagree, but this is my experience. For mesh systems - Qualcomm. You know the inner workings better.

MTK is getting a lot of attention at the moment because of the relationship with the OpenWRT team..

I like where they are at the moment... at least with the core SoC on Filogic - radios are ok for 11ax

QCA - yeah, ath9k (11n) is nice, as well documented, ath10k was pretty painful, even with ath10k-ct, ath11k along with ssdk is getting well sorted on the qualcommax target... qualcomm is getting better with ath12k on upstream contributions...

In a perfect world, I would have a MTK SoC with Qualcomm Radios
 
In a perfect world, I would have a MTK SoC with Qualcomm Radios

And mostly because MTK has done a better job sorting out the Hardware Flow assists with their PPE elements - QCA and NSS is still a bit of a mess - mostly due to docs and black-boxing..
 
Airtime Fairness - this shouldn't matter, but some of the Broadcom SDK's have issues here for some unknown reason
I remember back then, a lot of Wireless printers specifically had issues when Airtime Fairness was enabled.
 
Thank you guys again for the helpful info and suggestions.

Unbinding that Ring Bridge from my main router seems to have fixed the issue. For years I had it bound to one of the nodes, then more recently to the main router. Figured I was helping things... While I was getting hundreds of drops/reconnects per day, there hasn't been a single one since I made that change Friday morning.
 
Similar threads
Thread starter Title Forum Replies Date
E AX92u Mesh and rDevices roaming ASUSWRT - Official 3

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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