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.
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.
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 188.8.131.52. Same problems.
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.
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.