ePMP 1000 Standard WiFi AP dropping client connections

Dear all,

I am operating a few ePMP 1000 (NON-GPS) connectorized radios in standard WiFi mode.

Clients connect to the Standard WiFi Access points using mostly UBNT Airgrids and ePMP force 180.

It was working for a few weeks but now I am facing a peculiar issue where the AP drops the connections of clients every 12 to 24 hours.

Rebooting the AP resolves the issue and the clients reconnect to this AP successfully.

I have updated the AP to version 3.2 but it is not resolving the issue.

Every time this issue occurs, there are 0 clients connected to the AP.

I understand that operating Standard WiFi mode is only for migration but I am sure there are some operators who wants to run Cambium ePMP access points and retain UBNT clients.

What can be done to troubleshoot this issue?

Best regards,


I'm seeing this same thing on ver 3.5.

So, you are not alone. And it's frustrating as hell. I'm not sure what to do.


Standard WiFi mode is not reliable in long range outdoor deployments. Its a function of the WiFi protocol. It is accurate that Standard WiFi mode in ePMP is meant only for migration purposes and we do not recommended using that mode long term. 

If you wish to connect Ubiquiti clients to an ePMP AP, we recommend going the ePMP Elevate route where you will reap all the benefits and reliability of ePMPs proprietary TDD mode, still using Ubiquiti clients.

If you wish to operate the ePMP AP as purely a WiFi hotspot (not recommended for longer range outdoor deployments), I recommend using the ePMP 1000 Hotspot software which is a more mature WiFi solution.



No, your radio in that mode is not mature nor working proplerly.

When it kicks off customer radios and not let them back online when a previously working wifi AP worked fine, It's YOUR problem to fix. 

I can't stand arrogant answers like use a different device.

I'm trying to move over to elevate on these devices. But, yet again, Cambium wants me to build my network around them. I can't just elevate and lose a customer connection due to misalignment remotely. I HAVE to be able to associate to the new AP first (that is located at a different direction in our case) And it has to be in wifi mode until I get all of them moved over to this new 3 sector deployment that apparently is a waste of money and time.

Again, wifi mode in UBNT worked for years and years. Don't try to tell me epmp wifi mode doesn't work properly. If that is the case, fix it. Do you want some help??? Because I sure don't like spending thousands of dollars to be told to use something else later.

Hi Tristan, 

I apologize if my response came off as arrogant. I am not asking you to use a different device but merely stated that WiFi mode on ePMP is not recommended as a long term solution. The WiFi solution on ePMP is the vanialla WiFi firmware without the massive amount of tweaking that other vendors have done to make it somewhat work in a long range outdoor environment. Even with all that tweaking, its still not optimal and does not perform or scale as good as TDD mode. As you already know, both ePMP elevate and ePMP 1000 Hotspot solutions I suggested are software solutions. Not a different device. 

Can you elaborate more on the challenge you have with Elevating? Are you not able to hold the clients in WiFi mode long enough to load elevate software on them? One thing customers have done is load Elevate software on the clients while they are still connected to a Ubiquiti AP. Then they swap it out with a ePMP AP running TDD mode previously installed and prepped on the tower. Is this something that is not feasible in your case?

If you can explain your challenge a little bit more, I'm hoping we or other Elevate customers on this community may be able to suggest a better solution for you. 




Your AP is locking out customer radios for some reason over time. Wifi hasn't worked like that ever, in any environment. A simple reboot of the AP brings the customer radio back up without issue. 

No, I won't just elevate a customer radio over to a new site. This is a NEW tower, different than the original. So, it's not as simple as elevate a customer and they reattach to the new AP. We have to make sure the client can see and talk to the new AP. So, we are leaving them in wifi mode until we get them all switched over. Either remotely, or physically by realignment. THEN, we are going to elevate them and switch the AP's to TDD mode. (which currently isn't working because the new cambium AP is dropping the sessions at random)

Cambiums whole notion of putting up a second sector (or three) at the same site, turning on TDD and trying to run two systems at the same site is and always has been crazy.

I've experienced the same issue - with 2.4Ghz. It seems to be exacerbated by noisy environments.

The first sector we did took us about a week to get everything lined out before we actually elevated the customer CPE. Randomly the AP would drop all the customers and rebooting the AP was required to bring the CPE back online.

For a temporary fix since we are powering the AP with a netonix switch I just set a watchdog on that port watching a customer's IP address. It would reboot the AP when that CPE was offline. Not ideal, but it got us through until we were able to elevate all the CPE. Fortunately now, we are able to swap the AP radio (re-using the sector) configured in Wifi mode - get all the clients reconnected and then elevate the CPE within a few hours. 

I could see where if you are migrating sites that being in WiFi mode for an extended period would be necessary.

I like the idea, although as you and I both know, is a terible solution to this problem.

There is no way it's not a Cambium issue to be resolved. But oh well I suppose. I'm just a dumb customer buying their equipment.

For sure we have a high noise floor. Our new site is a half mile away sectorized, while our old site is an omni. It's a tough spot to be in. But, so we getting kicked off of a facility that we had been on for something like 5 years or better. None of it was ideal having to build a tower for one of their sites and moving to a cell tower for another. 

A ticket like this isn't the first one to hit this forum/community. I think it's terribly ignorant to say things like this isn't the right product to use, or just elevate. Cambium has an issue. They know about it clearly. They just don't want to be bothered to fix it.

In the beginning when ePMP was first released THERE WAS NO WiFi MODE. Then a number of customers asked for a temporary WiFi mode to be developed to ease transition. Cambium listened... I remember the whole conversation and back and forth and Cambium dev's made it very clear that the WiFi mode would be a bare bones temporary solution for transitioning clients, with the original goal being that you'd turn off Airmax on your Airmax M series AP, and then start swapping out Airmax client radios for ePMP radios in WiFi mode... then, when you got all the clients converted, you'd swap out the Airmax AP for an ePMP AP. From a product compatibility standpoint, it's going to be easier to make your client radio talk WiFi with a 3rd party AP then it will be to make your AP talk to 3rd party clients... making a compatible AP takes a lot more dev time and testing. You guys have to remember that even within product lines that are specifically designed for WiFi that incompatibility issues exist. It takes a huge amount of time making sure that vendor X's AP is interoperable with vendor Y's client device. I'd just be happy (and feel lucky) that it's an option and I certainly don't want Cambium wasting ANY development time messing with this. They need all that dev time for all the fun 802.11ac products right around the corner.

1 Like

And if you can't transition those clients? Then what? Oh, maybe I should have just stuck with UBNT than???

@Tristan wrote:

And if you can't transition those clients? Then what? Oh, maybe I should have just stuck with UBNT than???

I'm just trying to explain the history of this mode and some of the reasons why Cambium isn't going to fix this. They have very limited development resources for legacy modes like this.

On the flip side you must be having enough issues with your UBNT network to warrant a transition. Why don't you try what I said... use a UBNT airmaxM AP with Airmax disabled... swap all the clients to ePMP in WiFi mode, and then swap out the AP? I think you'll have better luck in this configuration.

1 Like

Apparently, you can't read. 

Because that is exactly what I am trying to do.

We can't go to every customer on the previous site in one day, re-align, and or relocate to get best signals to the new Epmp site. And by time we get this done, I have already done reboots on two of the three new sectors a few times because they stop accepting and keeping wifi connections.

Apparently I'm the one that can't read, but eff that. I'm not climbing this tower all those times just to swap out AP's when the entire purpose of elevate is to not have to do crap like that.

It's alright. I'll figure it out somehow. I remember all of these stupid things I come across though. And it's pushing me back to UBNT honestly. It's not my first rodeo with elevate and dumb issues that make it unstable and not always the best choice.

@Tristan wrote:

Apparently, you can't read. 

Because that is exactly what I am trying to do.

You say specifically "Your (ePMP) AP is locking out customer radios for some reason over time. Wifi hasn't worked like that ever, in any environment. A simple reboot of the AP brings the customer radio back up without issue. "


So are you saying that you've tried using a UBNT AirmaxAP w/Airmax off (so WiFi mode) and that the ePMP clients in WiFi mode are having issues? Because if that's what you're trying to do, then your posts are not clear.

I am swapping from a UBNT omni site, to a new, seperate near by site that is Epmp sectorized in wifi mode.

The UBNT radios (that I plan to elevate after I switch them all over to the new site) are dropping connection to the New EPMP AP's and NOT coming back. You have to reboot the epmp ap to have them come back.

This is a known, and talked about bug apparently that has been going on for a while now. It's in this forum, as I searched for it, and I think I even replied to it which reopened this thread.

Hi Tristan,

I want to understand your flow better. Why don't you want to Elevate radios the same time you switch them to a new site?


Mainly because it is at two different sites. So, one, we have to make sure the SM will even talk to the new site properly, with proper signals and such. Two, because if I turn on TDD on the new site, it's going to walk all over the old site while I'm trying to converge to the new site. They are NOT in the same location. New site is about half a mile North of old site. 

There are a lot of moving parts in this move. 

And., if there is an issue, we don't have the resources to dedicate a day plus to fixing every customer that we are moving over. There are close to 30 customers we are moving. Some with LOS, others we have to realign. Some, we may even lose to this move. The entire move was forced. So, we built a new tower, and are migrating as we can.

IMO, the best way I could figure to do this was to turn off Airmax, and set the SM's to Wifi. Leave wifi on at the new tower and move the customers that I can remotely to the new site in wifi mode. Than I'm having my guys physically move some customers over to the new tower as we have time, by realignment and even in a couple cases so far relocating the sm on the customer house for proper signals. My thought, after all were moved, was to then turn off the old site, then enable elevate and TDD on the new tower so it all worked properly.

I'm thoroughly aggrevated that yet again Cambium has told me to just do it a different way. Your product should work the way it is enabled, and I wouldn't have an issue.

I'm not asking for the best performance, or it to even work any better than typical wifi mode would in an outdoor environment.

I am asking that it not kick off the clients and not let them reassociate without a reboot. That is wrong, and it should not happen.

So, do you think it's OK for your AP to drop connections and not let them back on with out a reboot?

@Tristan wrote:

So, do you think it's OK for your AP to drop connections and not let them back on with out a reboot?


We don't think it is OK.

We were trying to propose you workaround which can work for you today, because defect fixing will take time. 

Could you please provide more information on that issue?

System logs from AP and SMs(with ePMP FW) would help a lot.

Also could you please attach configuration files in JSON format or sent them to me at Fedor.trutsko(at)cambiumnetworks(dot)com ?

Thank you.

Thank you.