EAP225 v3 APs frequently lock-up / disconnect with 5.1.6 firmware
I have run 3 EAP225s in my setup for several years with no real issues.
I finally decided to go further with Omada and deployed an OC200 & adopted the APs in (factory reset, then adopt & configure).
They were on a firmware from 2022, so when the OC200 offered to upgrade them, I went for it.
They upgraded and all seemed good for about a day. Then one of the 3 APs dropped off. I tried to get to its webpage directly, but no response. Power cycling brought the unit back. But about 10 hours later it went offline again. Same issue--complely locked up, green light on front.
I power cycled it again and decided to downgrade it to 5.1.1. I'm now watching to see what happens.
Just after I this, a 2nd AP (still running 5.1.6) had an identical issue. Power cycle and it came back.
A couple of hours later, the 3rd AP (also running 5.1.6) had the same issue. I power-cycled it and within an hour it did it again. So I have now downgraded that one to 5.1.1.
I'm keeping one of them at 5.1.6 and the other two at 5.1.1 to observe. But I suspect there is a hard lockup in 5.1.6 on this v3 hardware somewhere. I searched 1st and found a couple of threads of people with Outdoor versions of the EAP225 v3 reporting what sounds like the same issue.
What is the most stable firmware to run on them?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Which firmware version does your controller currently have? For firmware V5.1.6, the suggested controller version is Omada Controller v5.9 or above Please make sure the controller is compatible with this version. In addition, how are those three AP powered? Since it appears that the AP is locking power and then shutting down, please make sure they have enough power to run them correctly.Please also confirm whether they work properly in standalone mode.
- Copy Link
- Report Inappropriate Content
The OC200 is running 5.14.26.23 -- latest available for the hardware.
The APs are all powered by PoE and have been for years, just in standalone until I recently brought them into a controller setup. Nothing has changed with their power.
i did notice last night that somehow mesh was turned on in the site settings--maybe I accidentally set that when initially deploying. They don't need mesh as they all have a GigE backhaul.
I disabled the mesh setting and currently have 2 of them on 5.1.1 and one on 5.1.6. They stayed up all night. I will see how they do today when there is much more traffic.
Thanks for the advice.
- Copy Link
- Report Inappropriate Content
Disabling mesh will likely have resolved the issue. You were probably creating loops which result in the port getting shutdown.
However, this probably means there is a bug in the AP firmware which doesn't cover the case of two wired AP finding each other and instead of ignoring the potential mesh link, start to set it up resulting in a loop.
- Copy Link
- Report Inappropriate Content
Well, it seems to have helped, but hasn't completely resolved the issue. After a couple of days with no issues, I returned everything to 5.1.6, and now it seems like every 12 hours one of them is locking up.
I may have to back down to 5.1.1 on all of them to get some stability, and hope there is another release down the road that helps. I was really looking forward to the 5.1.6 release, because it brought LLDP support, and Lock-to-AP (which would be really handy for a camera I have that likes to land on the wrong one).
Unfortunately, I can't see individual AP logs in Omada controller (or haven't figured out how to configure that), so it is unclear what they are doing when they lock up.
- Copy Link
- Report Inappropriate Content
After a few days of observation, have you seen the disconnect issue in V5.1.1? What is your network's topology? Where do you install the controller?
To properly analyze the issue, please run them all on V5.1.6, and we will create a ticket for you to check your backup file, log, and so on. Is that good with you?
At last, try connecting three short cables to the power source or leaving only one device connected to the poe switch to see whether this is the result of insufficient power.
- Copy Link
- Report Inappropriate Content
5.1.1 did fine and experienced no lockups.
I took them all back up to 5.1.6 and have had 2 APs experience a lockup, but nothing over the last 24 hours. Hopefully things are starting to stabilize.
My topology is:
ISP->ER7206->SG2016P
|----->OC200
|----->EAP225
|----->SG2008P---->EAP610
|----->SG2210P---->EAP225
|--->EAP225
Only one switch (the SG2210P) has more than one AP connected, and those are the only 2 things on that switch using PoE.
The SG2016P only has 2 PoE devices running: the OC200 and one of the EAP225. That's a pretty light load for that switch's ratings.
The switches aren't showing anything remotely approaching their PoE budget, and all of the runs are within 15 meters on Cat5e, which should be well within the norms for PoE/PoE+. Due to the physical realities of the installation, I cannot put them on short leads without taking them out of effective service.
I'm happy to try running 5.1.6 a few days longer & see how it goes.
An observation I will make is that I have seen at least one lockup happen when something else on the network was performing a firmware update (and I have had several updates to push out over the past few days as I try to stagger them and not do everything at once). I was updating another switch that isn't in the path of these APs. What I noticed was that I first saw a "Heartbeat Missed" from one of the APs, and then after some time it showed disconnected and wouldn't come back, nor could I hit its local web page. I don't know if this was pure coincidence or if the OC200 was busy enough with the update (which really should just be sending down a few commands and a really quick file transfer, then monitoring for the dev to come back online) to have missed an AP's heartbeat and something about that caused the AP to lockup. But I have also seen (twice) where one AP would lockup and as soon as I recovered it, another AP would lockup. So it "feels" like there is something systemic going on--especially as I never had such problems when I operated the APs as standalone for years. I'm hoping that now that everything is up to date, things will settle down and there will be some stability to the system.
- Copy Link
- Report Inappropriate Content
When making changes to the internet, the connection between the AP and the controller may not be steady, resulting in a stalled request to be managed by the controller. The lockdown may require some time to recover. Now that your internet connection is more stable. You can try monitoring the network to see if the same problem occurs repeatedly.
- Copy Link
- Report Inappropriate Content
Well, I didn't make any changes to the internet side. I noticed this when performing a f/w update to a switch that is not in the path of AP<-->OC200.
All was going well & seemed stable, but last night around 10:17 pm local time, one of the APs disconnected and has still (as of 10:16am the next morning--so 12 hrs) not come back online. I am going to need to do a PoE recovery to get it back.
Hank21 wrote
When making changes to the internet, the connection between the AP and the controller may not be steady, resulting in a stalled request to be managed by the controller. The lockdown may require some time to recover. Now that your internet connection is more stable. You can try monitoring the network to see if the same problem occurs repeatedly.
- Copy Link
- Report Inappropriate Content
Thank you so much for taking the time to post the issue on TP-Link community!
To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID240770007, please check your email box and ensure the support email is well received. Thanks!
Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.
Many thanks for your great cooperation and patience!
- Copy Link
- Report Inappropriate Content
Information
Helpful: 2
Views: 570
Replies: 9
Voters 0
No one has voted for it yet.