ePMP2000- AP KEEP ALIVE RX STUCK

Hi,

I have 3 sector ePMP2000. First ePMP2000 have 4 subscriber SM, 2 ePMP2000 have 3 subscriber SM, and 3 ePMP2000 have 2 subscriber SM. All ePMP2000 lost conectivity every 2-3h with subscriber SM and all have log massage:

Mar 31 11:05:56 ________ kernel: [99330.170000] SM[58:c1:7a:47:51:7d] aid=4 disassociated. Reason: AP KEEP ALIVE RX STUCK 
Mar 31 11:05:57 ________ kernel: [99331.170000] SM[58:c1:7a:47:41:c1] aid=1 disassociated. Reason: AP KEEP ALIVE RX STUCK 

Software Version is 4.4.3 for all ePMP2000.
 
Subscriber SM is ePMP Force 180 fw4.4.3, and ePMP Force190 fw 4.4.3

I have the same problem. AP 2000 client elevate sxt, Any solution?

Exact same problem here.  It's actually been happening since 3.5.2.  4.4.1 is the first software where this message was finally added to give a little bit more detail.  Makes these devices pretty much unusable.  3.5.1 works perfectly.  We've tried every single version since 3.5.1 and narrowed it down to somewhere between 3.5.1 and 3.5.2 that this issue was introduced.

Unfortuantely, with the new MAC range on the CPEs, you now can only use 3.5.6 or later which leaves us with no solution.

Hi all,
seems we have the same situation here.
Let’s explain our setup: ePMP2000 with fw 4.6.0.1, scheduler 75/25, Synchronization Source GPS, Synchronization Holdoff Time 1000 sec.
The clients are a mix of Force180/190/200 with fw 4.4.3
In my investigation on the problem, i think the issue of client’s drop for us, is a lost of the GPS sync, and the synchronization holdoff time very very low determine the problem, because without a synchronization source after 1000 sec, AP will stop transmitting in order to avoid significantly increased self-interference. A Work around it’s setting up holdoff time to 84600 sec. But maybe it’s a comunication problem between radio e GPS module.
I’m monitoring the situation now. FingerCross :grinning:

This was a known issue last year. Please update to 4.6 1-rc26 or newer for the entire cluster and all SMs that connect to this tower. If you are still having this problem, you need to reach out to Cambium Tech support as you may have another problem.

2 Likes

AFAIK, this was a known issue in 4.6.0.1, which (AFAIK) has been resolved in 4.6.1 firmware.
We’re running 4.6.1-RC27, which has resolved all known issues for us. It has also resolved virtually all BSA issues for most people, although there seems to have been some remaining 3000/BSA issue (which, is apparently the 1 remaining issue why it’s still a RC and not a Release). But, the point is - I have confidence in 4.6.1-RC27 on everything in our network, and no issues that I’m aware of.

1 Like

Ok…thank for the replies, but we have other AP with the same setup without this problem and at this time setting up a greater holdoff time seems working as a solution. I’ve reading carefully release note of 4.6.0.1 and 4.6.x fw without find this issue (maybe I missed the note). ​In next weeks we are planning to upgrade to 4.6.1

Since you are having problems and increasing the holdoff timer makes it work, you need the check and possibly replace your gps puck. Either with the new thick round one or a square one. The thinner round ones that these APs came with are know to have problems.

I would also update to 4.6.1-rc27 regardless as this is what (currently unless something is found that needs fixing) 4.6.1 is going to be. This will get you off a known problematic firmware and may solve your issue at the same time.

1 Like

I have the same problem using ePTP mode with my other link but with PTP TDD is doing good. Will try to update here once I have changed the settings.

Thanks Douglas and others
I updated my firmware and everything is correct
Thanks again ur my stress killer