All STAs disassociated. IEEE80211_REASON_TDD_STOP WTF?????

hi , i have this problem in a few aps. 

one is an epmp 1000 without sync ( has only 13 sm registered) , the second one is an epmp 2000. 

both are running fine and suddenly kick all SM except one of them (ramdon) . i reboot the ap and can be working for 1 ...3...8 ...10 days without a problem.... 

today i had same problem. 

versions are in EPMP 2000

and 3.5.6 in epmp 1000

any suggestions??


I have forwarded this to our support and development teams.

Is a problem that I also found with

You solve it if you mount the 4.4-rc30.

Found and solved thanks to the precious help of Dmitry (I thank him!!)


Thank you for sharing. Did by any chance Dmitry post the solution to the community?

I had the same problem with version 4.4.4


I am not sure we ever posted 4.4.4. Are you sure about the software version? What is the device you having trouble with?



There’s still happening in the versions software 4.6 and 4.5.5…

Any solution?!!?

Try using the 4.6.1 beta.

Hello, @Joice_oliveira !

Could you provide more details about your issue?

Please, let me know which devices are you using as AP and SM. Also you can pm me tech support files from AP and SM right after the issue accrued. So I can investigate.

To download tech support files:
GUI > TOOLS > Backup / Restore > Backup Technical Support File

And we are going to have 4.6.1 stable release very soon.

thank for your replys guys, i’ll send the tech file

Just a curious question: TDD_Stop is not an error but a log comment and has to do with the radio being shut off, what other log comments are preceeding it? This can also be caused by power issues so how are you powering your radios? is there a UPS involved? is it an online UPS or is it a cheaper switching UPS? small power disturbances can cause this behavior as well as config issues. (hence the tech file request)

There are many causes for this log comment but the root is the radio TX being shut off.

im using a pop-protect, all the powering is controlled and setting values to my server zabbix and mppt controller…

following, part of logging

mgtcomd: Error: generate credentials
aid=5 disassociated. Reason: COMMUNICATION LOS
aid=10 disassociated. Reason: COMMUNICATION LOST
mgtcomd: Error: generate credentials
mgtcomd: Error: generate credentials
mgtcomd: Error: generate credentials

analysis on the config issues, freq, and power supply is obvious, but start it now, no changes at all on PoP, so… im in the process of investigation and learn

It can be difficult to find some issues, especially when your just learning.

Pop protect is not a power supply. It is a monitoring device for various uses. It also has an unknow event cycle that it can capture, ePMPs tend to be very picky about power fluxes and as short as 1ms has crippled APs on our network. Zabbix has a 5min cycle which means it averages the events from the last 5mins so you may (almost never) not see it without using a capturing oscilloscope
There is no “right” way to design a POP power system. Most commonly used for small companies with little to no electrical engineering background is to use good UPS’s from companies like APC or Tripplite. These work and can do so very well if you spend the money on a double conversion based one. The small UPSs available in most consumer electronics stores are either switching (power flow stops for about 15ms) or line-interactive. These can work but ultimately cause issues if they are always switching on to battery then back as power fluctuates.
Most of us that have been doing this awhile have either gone full DC straight off the batteries (good for solar sites) or have one of many commercially available options provided. Either way you are getting a near custom setup that ensures that the power never flickers.

Have your AP send a copy of all logs to a log server (like rsyslog) and have the server send those logs to a separate log file. This will allow you to actually see what the event chain looks like without the web page cutting off the important parts. Also log entries that are side by side are not always associated so look at the bigger picture within the logs. A good understanding of linux logs will go a long way.

Config errors are usually found in the downloaded copy of the config not on the web page. usually it will be a compatibility statement issue and the log will point you at the right direction.

1 Like

Como faço montar o 4.4-rc30.?

I would download 4.6.1-rc27 from the downloads section: ePMP 3000/3000L / Cambium Networks Support and in the radio under the tools tab, select software upgrade, then select browse and select the correct firmware file for the radio type you are using. once it is uploaded to the radio, select upgrade. wait until its finished and do not let the power fail during this. then once your given instructions to do so, reboot the radio.

We are also seeing this on one of our APs. We see the “mgtcomd: Error: generate credentials” in the logs for each SM. Every SM is still attached to the AP but all have default 192 addresses. It’s like the AP stops processing all DHCP requests or something. Sometimes this happens multiple times a day, other times not for a week or two. Tried 4.4.1 and Same problems.


Get the beta firmware 4.6.1-rc26 or rc27. There is an issue with that does this and it is not noticed on the beta.

1 Like

I’d try the latest Release Candidate… it’s resolved this as far as I’m aware.
RC27 is a well baked Release, we’re using it on nearly all of our our PTP and PTMP ePMP APs/SMs and we find it stable. I believe Eric and Douglas and many others have it rolled out in lots of places.

1 Like

Yes, we are almost fully rolled to 4.6.1-rc27 now. There have been issues that caused us to roll the odd f180 back to rc26 but those were to confirm a hardware issue that was finally noticed once rc27 was posted. The roll back was to confirm it wasnt firmware related.


We upgraded to rc27 after your post and still continue to experience the exact same issue. Sometimes this AP runs for 7-10 days before having the problem, other times, it doesn’t even last 12 hours before having the problem again. I’ve submitted at least 3 different debug files to support and they can’t figure anything out. Rebooting the AP always restores all STAs instantly. Not sure what else to try.