Can ping PMP450M AP, passes traffic, but cannot connect to Web GUI

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.

Has anyone else seen this same issue?

What firmware are you using on the AP?

We have version Canopy 20.0.1.

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.

Thanks for chiming in, @rnelson. The issue fixed by CPY-16874 is specific to 450 AP and SM.
It does not address the issue in question.

@Aaron_Adkins, if you haven’t already, could you please open a ticket with support.

1 Like

Are these devices on public or private IP addresses?

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.

Out of curiosity, why are your APs on public IPs?


I can’t understand why. With a little effort you can create a mgmt vlan…

CBRS requires Public Access for the AP to function , that is why. Running a on prim Domain Proxy is not viable for large deployments.

I don’t know CBRS’ system, but… are you sure?
i think they only need access to cnmaestro (and not entire world has access to them!)

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.

1 Like

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.

This is absolutely not true. All of our CBRS APs are on private IPs.

1 Like

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.

Yes, it is helpful, because it started with this your very clear and misleading information:

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.