We have a PMP450M AP that keeps locking up to where we cannot access the web GUI. In order to be able to connect to the GUI is to power cycle the AP. After the power cycle we can access the GUI, make changes, and reboot the AP. Eventually the AP will freeze again.
During the time the AP is frozen we can ping the AP and the SMs that are connected to the AP can still browse the internet. When we try to connect to the AP’s GUI the initial logon screen starts to appear but gets stuck with in the ‘loading…’ page for the GUI.
Do you have access to the event log after a reboot? We just had a issue with a AP that has outside internet access for CBRS and cnMeastro get hit with a ntp attack on port 123 that caused the AP to be come none responsive but still ping. Resolved with proper firewall rules. Error showed in the log as “sntp failed to send()”.
We started having similar problems yesterday except we are using 450i and it is every tower and every AP. Once everything is power cycled it comes up and stays up for a while (30 mins, 2 hrs, depends). I have submitted a trouble ticket and am waiting for guidance.
This may be fixed in Beta build 4, hopefully someone from Cambium can chime in:
CPY-16874: A memory controller fix on 450 AP and SM that can potentially lead to a number of operational and UI issues including Webpage Auto Update failing to refresh and occasional crashes.
This was the cause of our problems as well. We put a firewall rule in place and it has resolved the issue. We have currently blocked over 3 million attempts. Thanks for the info.
They need to access the internet but they certainly don’t need to be assigned non-firewalled public IP’s. We use NAT with firewall rules and they work just fine.
The AP was behind a Firewall no equipment should or will ever be deployed without one. This issue was a misconfigured firewall rule which let the attacker in , even with nat , if the firewall and nat rules are not configured correctly they are useless. The bad thing about this that came to light is Cambium equipment is defiantly on attackers radar and know exploits are out in the wild which will be up to Cambium to address as fast as they can when they can identify them since most operators of Cambium gear do not allow the APs online access. With the hard push of cnMeastro Cloud I see this becoming a major issue sooner then later as more APs and SMs are being connected to the cloud.
Which either is connected to a cnMeastro domain proxy on prim , or nated to access the SAS directly. Moot point , the above reply is not helpful to the conversation.
We tried an abundance of the information that has been put out in this forum. We eventually changed the static IP that was on the AP and we have not had the problem come back. We will continue to monitor to see if the issue returns.
I’d argue it is very helpful. It’s not having internet access that is causing the issue, but having a public IP with no firewall rules.
Neither cnMaestro nor the SAS require you to have a public IP on your devices and many here would argue you SHOULD NOT have a public routable IP on any of your management systems.