Business CommunityWireless5Ghz clients can't connect to some EAPs after either switch or router upgrade
Wireless

5Ghz clients can't connect to some EAPs after either switch or router upgrade

5Ghz clients can't connect to some EAPs after either switch or router upgrade

5Ghz clients can't connect to some EAPs after either switch or router upgrade
5Ghz clients can't connect to some EAPs after either switch or router upgrade
2 weeks ago - last edited 2 weeks ago
Tags: #Mesh #VLAN & Multi-Networks #Roaming #Network Connectivity
Model: EAP610   EAP225-Outdoor   EAP610-Outdoor  
Hardware Version: V2
Firmware Version: 1.4.4

 

SUMMARY: after upgrading either ER8411 router or SX3832 switch using software controller v6.x, no clients could connect anymore to the 5GHz band on either all or a few EAPs, and rebooting or force provisionning those EAPs would not fix the problem.

 

----

 

Hi,

 

I picked the wireless forum because that's where ultimately the problem manifested itself, but it could be a controller or firmware issue, I don't know. Also, so far I always found a way to make it work in the end, so this is more of a "witness" report that I wanted to publish for reference rather than a formal bug report.

 

I run a software controller on Linux, currently v6.2.10.17. The issues I'm about to describe arose *only* after upgrading the controller from v5.15.24.19 to v6.x, so that's why I think this might be a controller issue, but it may also be just a coincidence, I don't know.

 

Here is my toplogy:

 

 

Here are the devices and firmware details:

 

 

Here are the SSIDs:

 

 

Note that shrodiwf is only on the 2.4GHz band, while shrodiwfv and shrodiwf5 are only on the 5/6GHz bands.

 

I have a few VLANs; the default (native) VLAN for WLAN is 100 (and therefore untagged). shrodIoT is the only SSID not on the default VLAN, and therefore tagged, but that is not really important here.

 

Now here is the problem: a while after upgrading the controller to v6.x, there was a new firmware version available for the ER8411, so I did the update. At this time, I didn't have the SX3832 yet: this is a more recent acquisition (this is important because what convinced me to write the current report is a recent update on the SX3832 that triggered the same problem), so all my EAPs were connected to the ER8411. Note that I did such updates on the ER8411 with controller v5.x in the past and there were no issues. After updating the ER8411, I noticed that no client could connect to shrodiwf5 nor shrodiwfv anymore (but shrodiwf was fine): *all* the EAPs (I didn't have the EAP773 at the time, though) would reject any connection attempt to those two SSIDs (the clients prompting to renter the password after trying). So the SSIDs were visible, the clients would try to connect, but could not. I tried rebooting and force provisionning all the EAPs, but to no avail. Finally, desperately trying anything that could come to my mind, I changed the native VLAN on the ER8411 ports for the EAPs to the gateway default (1) and then switch it back to 100. Magic! Everything started working again! And this happened twice, each time after an update of the ER8411 using controller v6.x, before I got the SX3832.

 

After I got the SX3832, I moved most EAPs on it, and I added the EAP773 (see toplogy above) and added the SSID shrodiwf7. Recently there was a firmware update for the SX3832, so I installed it. I noticed nothing immediately after the reboot, because the EAP773 was working fine and it's the most central EAP, but 1 or 2 days after I realized that roaming would not work on shrodiwf5 or shrodiwfv when going in the "EAP610 Patio" and the "EAP610 CourArriere" areas, even losing signal altogether when going too far into those areas. I confirmed that those two EAPs would not accept 5GHz connections anymore, the exact same way as described previously. But the EAP773, "EAP225 André" and "EAP610 CourAvant" were all right (did not test "EAP225 Serveurs", because I only need 2.4GHz on this one). Besides the fact that not all the EAPs were rejecting connections on the 5GHz band, it looked a lot like the problem I had with the ER8411 updates, so I changed the native VLAN on the appropriate SX3832 ports to 1 and then back to 100, *but this time nothing changed*: the problem was *not* fixed. Rebooting and force provisionning didn't work either. So I was back to trying random stuff. What finally worked (and something I had never tried before) was linking "EAP610 CourArriere" to the EAP773 instead of "EAP Patio": suddenly, both "EAP610 Patio" and "EAP610 CourArriere" started accepting 5Ghz connections again. When I linked back "EAP610 CourArriere" to "EAP Patio", everything stayed fine, and still is.

 

So really I don't understand what's going on here. Maybe the two problems are not even related, I don't know. And why the EAP773+"EAP610 CourAvant" were not affected after the SX3832 update? All I know is that it's quite a bit frustrating.

  0      
0
#1
Options
2 Reply
Re:5Ghz clients can't connect to some EAPs after either switch or router upgrade
22 hours ago

Hi  @shrodi 

 

Thank you for the detailed report.

Based on the detailed description you provided, the issue emerged following specific network change operations, with complex manifestations and varied resolutions. This appears to be more of a sporadic configuration synchronization or state anomaly triggered by the confluence of multiple coincidental factors within a specific, complex network environment, rather than a widespread product defect.

The following analysis is from the perspective of network configuration and state:

  1. “State Sticking” Triggered by Network Configuration . The core characteristic of the problem is that the significant change operation of device firmware upgrades may have triggered a special state in the network underlay (switch). In this state, the VLAN configuration (particularly the Native VLAN settings) on certain ports failed to fully synchronize or correctly apply to the connected EAP devices. Your operation of temporarily switching and then restoring the port’s Native VLAN was essentially a forced state refresh, clearing this “sticking” and allowing the configuration to be properly applied. This pertains to a sporadic state issue that occurs under specific conditions at the network protocol layer.

  2. Subtle Influence of Network Topology and Dependencies. The different manifestations and solutions for the two incidents are likely due to differences in network topology. The first time, all EAPs were directly connected to the ER8411, making the problem global and uniform; the second time, EAPs formed a more complex hierarchical structure via wireless backhaul (Mesh), resulting in localized symptoms.

    • The operation of changing the uplink device for “EAP610 CourArriere” may have solved the problem because it completely rebuilt the network path and dependencies for the affected EAPs. The wireless backhaul link might have retained old, unstable state information after the firmware upgrade, which a simple reboot could not clear. Forcing a change in its parent node essentially broke the original “problem state chain,” triggering a complete reconstruction process for the link and its associated configurations.

  3. “Timing Coincidence” of Controller Upgrade and Network Changes . The issue was only observed after upgrading the controller to v6. x. However, this is likely a coincidence, or perhaps certain background optimizations or state-checking mechanisms introduced in v6. x subtly interacted with your unique network environment (multiple VLANs, mixed wired/wireless backhaul) precisely after the sensitive operation of a “device firmware upgrade.” This is not a fundamental error in the v6.x controller; rather, its logic for handling network state synchronization failed to adapt perfectly to a major underlying firmware change, given the specific configuration sequence and time window of your network.


Since your network has already been restored on your end, and we need to reproduce the issue and preserve the environment to identify the root cause, we will continue to monitor similar feedback.
 

Wish you a happy life and smooth network usage!  Help Us Improve - Omada AP Installation Guide >Get the Latest Omada SDN Controller Releases Here< >Get the Latest Firmware Releases for Omada Routers Here< >Experience the Latest Omada EAP Firmware<
  0  
0
#2
Options
Re:5Ghz clients can't connect to some EAPs after either switch or router upgrade
13 hours ago

  @Vincent-TP Thank you for your analysis. I'd like to add a few details I'm just realizing I didn't mention explicitely:

 

  1. Before I got the SX3832 + EAP773, "EAP610 CourArriere" was already meshed to "EAP610 Patio", and "EAP610 CourAvant" was also meshed to "EAP610 Patio"; "EAP610 Patio" and all other EAPs were directly connected to the ER8411. So the meshing already existed before I got the SX3832.
     
  2. I would like to pinpoint that only the 5GHz band was affected: the SSID "shrodiwf" (2.4 GHz) never stopped accepting connections on any EAP, and it is on the same VLAN (100) as SSIDs "shrodiwfv" and "shrodiwf5".
  0  
0
#3
Options

Information

Helpful: 0

Views: 156

Replies: 2

Tags

Mesh VLAN & Multi-Networks Roaming Network Connectivity