Epmp3000L stations dropouts

Hi, I need nelp please.

This AP is a 3000L, there a 8 stations linked to it, a mix of 300-13, 300-16 and 1 300-25. Some of the stations are being kicked out ramdomly once or twice a day, not all of the stations, only some. Any idea please?

So, first thing is the IP addresses for your radios there are publicly accessible. When I can enter one of those IP's in my web browser and bring up the logon for your customer's radio. That is probably the biggest DON'T EVER DO THAT ! that exists.  At the very least change the port.. that is the "least". You really shouldn't allow the radio interface to be accessible by anyone except your techs and you really really really don't even want a public address on it. 

So first thing possible is the radios are being DOS attacked or who knows what.  When we first started doing wireless back in the day, we started with a 900Mhz solution from Wave .  The radio's interface was publicly accessible and after days of trying to figure out why our radios were rebooting every hour or so we discovered data packets from random RIPE ip addresses were hitting the radios and causing them to reboot.  So there was a known vulnerability and someone out there was enjoying crashing our radios.


Make sure the Spectrum Analyzer isn't on... The SA just causes all kinds of problems right now if left on.

Another option is, what version of firmware are you using ? We, like just about everyone running AC right now, have seen this problem fairly often and one thing we have found is AC does not like it when everything isn't running the exact same version of Firmware . At least make sure all the client radios are running the exact same version of firmware. 

However in at least two instances were we seen this problem on a 3000L with mixed clients (N and AC) running 4.3 on the clients and 4.1 on the AP seemed to resolve the issue, for a while then it came back mysteriously and we found the ultimate fix was replacing the 3000L with a  2000  and now all problems are fixed.

That said, interference can also be the issue and the SA  may be able to show that is the problem but it's so slow you will have to leave it on for a long time and if that wasn't already the problem you are really going to have a problem while it ever so slowly scans / wrecks everything.  Or just trying a different channel may help.

Haven't done much with the beta 4.5 stuff you might give that a try if you haven't already.

1 Like

Just to mimic what brubble said, you also have default logins enabled on a couple of these radios, so they're totally accessible from the internet.

Very bad security practice. There's nothing stopping someone right now from logging in and changing any settings.

Disable the spectrum analyzer on the SM and AP. Upgrade to the latest beta firmware, get rid of public IP's on each SM or at the very least firewall them off so only your management network can reach them. Enable NTP to get accurate times for your logs, change the default SNMP value, remove backdoor accounts, update your WPA2 key to something not so obvious, change your VLAN priority from 7 to 0. If all your SM's are setup the same you're doing yourself a disservice by having vlan priority set to 7 on the SM. Stop using 8.8.8.8 and 8.8.4.4 as DNS servers, build your own.

I've never thought that letting the SM be the router was smart, but there's people that do it apparently. I'm of the mindset that you should let a router be a router and let the SM do SM stuff.  I would switch to bridge, install a router, and let that do it's job.

You're also running in violation of your countries wireless rules. Your country is set to "Other" instead of your actual country, and you're way over powered for transmitter output power on the SM and I assume your AP. You're also transmitting on an unauthorized chunk of spectrum for your country.  

Watching a radio for the last 20 minutes I can see your problem is most likely due to the fact you have spectrum analyser turned on constantly. It looks like the process is crashing and taking your SM down along with it. 

Fix all those issues, then see if the drops stop. If not, submit a ticket with Cambium. 

1 Like

Cambium should remove those attached pictures with the IP addresses until those radios are locked down...

1 Like

Looks like Cambium just took down my post. You have a lot of problems here OP. Suggest removing all content and getting a network tech in to evaluate the network. 

1 Like

I should have gone about that in a different way. I didn't realize until just now there is a "report post" option. That would probably have gotten it fixed faster. In my defense I didn't realize just how bad it was, it never occured to me to try to actually log into any of them (I'm thinking that's technically not legal in some places even if you are trying to help). Still, I think that would explain why your post was removed but not sure why the attachment wasn't removed at the same time instead quite a while later.

I removed the first attachment (that had public IP addresses in it).

Thanks all for the advices. Never again public Ip addresses then.

All modulations are almost perfect, all radios using same 4.5 version and all clients force300. Moved channel from 80mhz to 40 mhz on to a cleaner one, no lost pings etc. And I still see many disconnections. Also the disconnection code is 48 which means check for quality of radio connection. 

You also need to change your passwords from the defult.

Did you turn off the spectrum analysers? 

Also upgrade to the latest beta. 4.5.4 R7

  Yes, all SA are disabled. All running on 4.5 version. From your experience, is 4.5.rR7 a better and more stable version?. I'm affraid of doing more changes here.

Cheers

Yes, all SA are disabled. All running on 4.5 version. From your experience, is 4.5.4 R7 version more stable?

Cheers.

Dimas


@dimas j perez wrote:

Yes, all SA are disabled. All running on 4.5 version. From your experience, is 4.5.4 R7 version more stable?


To thow my 2c in - yes, we are running 4.5.4-RC7 on all our 3000 L and 3000 MU AP's and all Force300 SM's, and we are not having any major show-stopper issues... at least nothing which makes me want to roll back to 4.5

Thank you for your advice. I'll try to upload firmwares tonight and see how it goes.

4.5.4 RC7 is realy buggy firmware for E3K and E3KL (Multiple device reboots and clients kickout)


@Majk wrote:

4.5.4 RC7 is realy buggy firmware for E3K and E3KL (Multiple device reboots and clients kickout)


Your mileage may vary. :)  This new AP for us has everyone connected, with no random dropoffs. But there is only 6 clients - and there are no mixed "n" or 'elevated' clients either.  

4.5_SM_UPTIME_JULY_2020.jpg

But yes - certainly 4.5.4-RC7 does have bugs (it's a just a release candidate) and also Cambium said something a few days ago to the effect of "one major show stopper remaining" when someone was asking when the 4.5.4 Official Release was going to be.  So it might not be better for his purposes, but it also might be... hard to say without trying it IMHO.

Yes, i think the same. I have raised a ticket and I'm gonna wait an official answer. Thank you.

4.5.4 r7 has been relatively good for us, mixed force 200 and 300 clients on 3000 and 2000 hardware, no real problems. Don't have any 3000L in the network though.


@ninedd wrote:

@Majk wrote:

4.5.4 RC7 is realy buggy firmware for E3K and E3KL (Multiple device reboots and clients kickout)


Your mileage may vary. :)  This new AP for us has everyone connected, with no random dropoffs. But there is only 6 clients - and there are no mixed "n" or 'elevated' clients either.  

4.5_SM_UPTIME_JULY_2020.jpg

But yes - certainly 4.5.4-RC7 does have bugs (it's a just a release candidate) and also Cambium said something a few days ago to the effect of "one major show stopper remaining" when someone was asking when the 4.5.4 Official Release was going to be.  So it might not be better for his purposes, but it also might be... hard to say without trying it IMHO.


I wil throw in my 2 cents.....

I have 2 out of 12 epmp 3000 running 4.5.. the other 10 are running 4.4.3.   I had one epmp on 4.5 with 6 subs and I noticed that my uplink/downlink rssi and snr was more unstable with 4.5 but never have had any "show stopper" isues on it.  I have a epmp 3000 with 20 subscribers that was running 4.4.3 without a hitch, working beautifully.  Upgraded to 4.5 and all my 20 subs rssi and snr went to crab, no other changes, just sofware from 4.4.3 to 4.5 and I have had "show stopper" instances ever since.  The epmp 3000 will go down, dropping all clients as well and then everything is back to normal 30-45mins later.  Everything comes back on its own.  Maybe the difference is the amount of subscribers but either 6 or 20 subs my uplink/downlink rssi an snr worsen when switching from  4.4.3 to 4.5.  I will switch back to 4.4.3 and await the next software revision of 4.5.

Yes - I've heard a number of people say that 4.4.3 worked for them, and since then it's been issues.  I think basically as Cambium has been working on the Beam Steering Antenna -- that's introduced some issues maybe?

Anyway - we don't have highly loaded APs, and we basically have stopped deploying Cambium... the AP's are 2x too expensive and that "might" be OK if they were 2x better... but they just aren't.  So - for us - the RC7 is working OK, but that may be because most of them they are mostly just lightly loaded too.