450i AP stops passing traffic and responding to pings

We have a 450i AP that has twice in the past 24 hours stopped passing traffic and responding to pings, once for 2 hours,  then again later for 30 minutes.  All the SM sessions stayed up, and there is nothing in the AP stats or logs to indicate there was a problem.  The AP shows the Ethernet session has been up continuously, and the Ethernet switch the AP is connected to also does not show that there have been any Ethernet problems.  Both times it came back up on its own, we didn't do anything to get it back working.  I have subsequently rebooted the AP but basically because I can't think of anything else to prevent it happening again, other than to replace the AP.

The AP is running 15.2 FW with Cambium Sync, this is not a new AP, and we have 9 other 450i APs at the site with no problems.  I can't recall ever seeing this problem before.  Does it sound familiar to anyone?

I've never seen something like this happen. I'm curious, when you're able to get back into the AP, does it have any interesting logs or show any errors on the ethernet interface?

I think I'd try to update it to 16.0.1 and see if that fixes it. There's been quite a few bug fixes since 15.2.

Nothing in the logs.  The only thing I found was one message in the (Cisco 2960) Ethernet switch log about a MAC address flap between the port this AP is on.  The MAC address in question is the tower router.

I don't see any possibility of a loop in the network architecture at this tower, so that's kind of strange.

Hi Ken,

I'm sorry to hear you are having issues with 450i APs passing traffic.

I you run in to this issue again, could you please get "engineering.cgi" file from the AP, while it is not passing traffic.

Please send the "engineering.cgi" file to me at balaji.grandhi@cambiumnetworks.com.



That is very strange behavior as there are watchdog timers that will kick the session for non-responsiveness well before 2 hours, etc... 

I don't know why certain statistics wouldn't show you an issue in any logs.

Like Balaji said, if it occurs again, please capture what you can so we can dig in further.