Clients refuse to connec to the nearest AP

Kekkis · September 10

I have many Shelly wlan relays that are connected to my Nexus managed APs. Somehow they often end up trying to connect to a far away AP instead of the really near one and keep failing on connection.

Here they have all disconnected when the nearby ap switched channel at 3am. Signal on that AP was great.

After this they just keep trying other APs but not the closest one.

This gets fixed if i change any settings in the AP "Radio settings" configuration. For example now changed "Disassociate Station Threshold" from -70 to -71 and all clients instantly reconnected to the closest one.

This does not show up as any change in this AP event log like changing a channel. The clients just hop on.

Any idea what prevents these clients connecting to the nearest ap which has great signal?

Zyxel_Nami · September 10

Hi @Kekkis

We assume that the nearest AP you're referring to is Autotalli. Could you confirm if all clients are attempting to connect to the distant AP, or is it only the Shelly clients you mentioned?

To investigate further, please enable Zyxel Support Access and provide your Org/Site name.

Kekkis · September 10

Yes, autotalli is the nearest one. I only have shelly clients there. If i bring my phone near the AP it does connect to 5ghz even while shellies are failing. I sent a message about the site details.

Zyxel_Nami · September 11

Hi @Kekkis

Thank you for your provided information.

As you mentioned, the disconnection from Autotalli occurred after the AP switched channels at 3 AM due to the Dynamic Channel Selection (DCS) process.

During DCS, clients may be briefly disconnected as the AP adjusts its channel. Afterward, clients will attempt to reconnect and may roam to another AP if the signal is stable. It's normal to see clients remain connected to a farther AP if its signal is strong and consistent, even after a channel change on the closer AP.

Kekkis · September 11

Yes, dcs causes them to disconnect in the first place. But the problem in my case is they never succeed in connecting to any AP (and not even trying the nearest one) until i go and refresh one of the radio settings. The further APs don't take the client for some reason "blocked by key handshake fail" and their signal is below the configured "Disassociate threshold" so they should steer away.

Zyxel_Nami · September 11

Hi @Kekkis

Could you clarify whether you changed any radio settings after DCS progress (at 3 AM) on both September 10th and 11th? and which settings?

I’ve reviewed your site and noticed that most Shelly clients are connected to the Autotalli AP as expected. The other three Shelly clients are connected to other APs whose signal strength appears fine, as per the screenshot I shared with you via private message.

When the issue reoccurs (Shelly clients disconnect from Autotalli and can't reconnect for a long time after DCS), please provide the timestamp of when they fail to reconnect and share the affected clients' MAC addresses via private message.

Given that the Autotalli AP is somewhat isolated from the other APs and primarily handles Shelly clients, I recommend configuring a separate SSID for these clients. You can then use the SSID tag feature to ensure only the Autotalli AP broadcasts this SSID, specifically on the 2.4GHz band, which is compatible with the Shelly clients.

For further instructions, you can refer to this guide on configuring a unique SSID on specific APs in Nebula: How to configure unique SSID on specific access points on Nebula.

Kekkis · September 11

Today dcs didnt decide to switch channels so everything stayed connected "Radio2 cannot find channel better than current channel 48"

Yesterday 10th september the sequence was this:

3am dcs changed channel and all shelly clients on that ap disocnnected
Those clients kept trying to connect to the other aps until:
11:58am i changed the 2,4ghz disassociate threshold from -70 to -71 (to my experience any setting works, seems that they just need a refresh. I usually just switch this back and forth to trigger this). Didn't change any other setting at any point.
Clients reconnected to the nearby AP without performing any actions on their end

Yes i have shelly clients elsewhere on the property and they connect to other APs. This problem doesn't happen with them. Maybe they always have another AP nearby if they disconnect when dcs changes channel.

Macs are in the screenshots. All the ones that go red are the affected ones.

Yes I could set up many ssids and manually point all static clients to nearest ap but I thought the whole point of system like nebula is that i don't need to do that.

Zyxel_Nami · September 12

Hello @Kekkis

Thank you for the details.

Regarding Radio2, it's designated for 5GHz, so it's unrelated to the disconnection issue with the Shelly clients on the Autotalli AP since those devices only support 2.4GHz. In the screenshot from September 11, you can see that the Shelly clients successfully reconnected to the Autotalli AP after the DCS changed the channel from 11 to 1.

On September 10, the situation seems similar to September 11. The Shelly clients reconnected to the AP via 2.4GHz at 03:02:22.

On September 9, I noticed "netconf connection connected and disconnected" logs across all APs between 02:05:17 and 04:50:08, indicating a possible disconnection with the uplink device (router).

For the Autotalli AP, the last netconf log was at 04:43:43, and the clients reconnected via 5GHz at 09:53:38. Regarding the 2.4GHz clients, they reconnected at 11:56:20 after your configuration change. We'll need diagnostic information for further investigation to understand why the clients didn’t reconnect before that change. To collect the diagnostic info, you may refer to this FAQ.

Clients refuse to connec to the nearest AP

All Replies

Categories

Nebula Tips & Tricks

Nebula Help Center