We have multiple PMP 450 SM's connected to an AP that at least once a week stop responding to ping. They are still connected to the AP and passing traffic but do not respond at all. The way we have found to fix this is to drop the session from the AP and have it reconnect. This would be fine if it happened every once in a while, but it is happening once or twice a week. I have looked through the fourms but do not see anything on this. If you could help that would be great. Thanks.
What software release are you running? Are you able to access the SM via browser directly to SM? If not, are you able to access the SM via the Session Status List on the AP?
We are running 13.2.1 on both the AP and the SM's. We are not able to hit the SM via browser or through the session status list. The SM shows up as "IN Session" on the status list, but we cannot hit it. Again, the SM is still passing traffic even though we cannot get to it.
Is the address a public IP?
No it is not.
I would like to look into this further including CNUT captures. Would you be willing to open a support ticket? http://www.cambiumnetworks.com/support . Support--> Open a Support Case.
I had a similar experience with a radio in the field today. One of our techs mentioned that a radio in the field would stop responding to routed traffic after 5 minutes or so. We operate our PMP450's as bridges with a management VLAN. The management IP of this one radio would stop responding but it would continue to pass the customer traffic, so the customer didn't notice. I could telnet to the unit from the router, but couldn't access it from elsewhere despite ipconfig showing correct information.
This radio was running 13.2. I rebooted it and managed to have CNUT push out 13.2.1 before it stopped responding. It rebooted and came up and has been fine for the past 3 hours. I didn't do any other diagnostics and moved on.
I have had the same issue over 7 different AP's. Once a week we lose an SM. Can't ping/telnet. Customer traffic is fine although there network monitoring software goes crazy.
The only way that we could find to resolve this was to reboot the AP. Of course this then knocks all other SM's off until re-associated.
All AP's are on the most up to date code.
Has there been an update on this?
Have you tried to enable the "Packet Flooding" feature on the AP? This is on the Configuration -> General page.
Historically, and by default, the Canopy AP won't forward unicast packets whose destination MAC aren't in its Bridging Table. There were and are valid reasons for this, but it exposes you to issues with ARP / Bridge table timeout mismatches. You can enable this option (it doesnt require a reboot to change), and when it is enable, the AP will forward out unknown unicast packets to all of the SMs in order to solicit a response from which the AP will learn in the upstream reply.
This is how normal 802.3 switches work when an address entry times out - flooding the packet to all ports expecting to see the response from the proper single port. For Canopy, the upper level ARP request that should come eventually (but maybe not for minutes or hours depending on the ARP cache timeout) will flush out a unicast reply which would then be learned by the AP.
If you have tried that, and the problem still happens, we would like to see a debug capture of the AP and information about which SM you are trying to reach.
Carl,
Instead of rebooting the AP and loosing all the customers while the AP reboots, go into the AP>Tools>Sessions.
Select the SM, select Local then "Dorp Selected Sessions".
This will drop the session with the selected SM and once it reconnect you should gain access..
We have one 13.2.1 PMP450 AP that stopped responding to pings last night. SMs are still passing traffic. Can't web browse to it, can't connect in CNUT. Management VLAN is enabled. We can remotely power cycle, but figured I'd ask first if there is something I can do otherwise, or if there's a way I can help in determining why this happened.
@Carl MacKean wrote:I have had the same issue over 7 different AP's. Once a week we lose an SM. Can't ping/telnet. Customer traffic is fine although there network monitoring software goes crazy.
The only way that we could find to resolve this was to reboot the AP. Of course this then knocks all other SM's off until re-associated.
All AP's are on the most up to date code.
Has there been an update on this?
I've the same issue, but if you don't want to disconnect all the client from the sector you can drop only the session of the SM affected by this problem from Tools -> Session.
Are your sm’s showing up in a registering status on your ap?
@Brian Sengele wrote:
Are your sm's showing up in a registering status on your ap?
Yep, the SM is always "In Session".
We are seeing this on one of our APs. The AP becomes inaccessible (no ping) but is still passing traffic and I can get to all the SMs behind it. I haven't tried the bridge flooding setting change yet as that looks like it is for the issue where SMs are dropping off rather than the AP but I did find (and this may be a hint) that clearing the ARP cache for the APs IP address on the upstream router brought it back. No reboot necessary. I wouldn't worry about it at this point except that both Nagios and Cacti don't work in this situation.
Can someone tell me why this might be happening: I lose access to Cambium AP but all the SMs are pinging and passing traffic. I do a show ARP and the MAC address is correct. I then do a clear ARP for the IP address of the AP and it starts pinging again. It happens only to 3 of the 6 APs on site, 2 100 series and the other a 450. Ideas?
i having the same issue that sometimes i can not ping SM's and also no traffic passing through but radio still registered on the AP
am using software version 15.01 at both AP and SM. can any body help me
We will be releasing 15.1 this Friday. I would recommend upgrading software to this version, as we fixed a bug that has similar symptoms.
Noted and thanks, am waiting. currentlly i have upgraded to 15.0.3 but problem keeps persist
up to now i didnt find any new software release of 15.1. any update