Any of you had any issues with Cambium radios coming up, but not responding to pings? I tried 169.254.1.1, 192.168.0.1 and 192.168.0.2. These are all newer than the migration to 169.254. I seem to have two radios on a tower doing that.
We're starting to possibly see this issue too on a couple of our PtMP sectors, strangely enough... not all of them, just a couple... the symptoms we're seeing are that client's WAN IP doesn't respond to pings for a small amount of time... usually somewhere between 5-30min. The client is still associated to the AP, and we believe the client can still access the internet (need to validate this), just no ICMP back from the client's WAN IP... and then after awhile, it will magically start responding again.
We just caught one in the act, and we deregistered it from the AP... it then came back, and is now pingable and the management interface is accessible again.
Does this sound like the issue you're having?
Not sure if this applies to your situation, but I've noticed that the cambium will not forward unicast packets if it doesn't have an entry in its bridging table. Once the client initiates some traffic the bridging table will re-populate and pings will work again. Another way to force an entry in the briding table is to clear the client's ARP entry on your router. Your router will then broadcast an ARP request, to which the client will respond, thus re-populating the bridge table. This specific issue is mostly cosmetic, unless of course you're trying to host a server across a wireless link.
We use the WAN IP on the client for an ICMP heart beat and latency monitoring. We never had this issue before 2.4.3... .so something must have changed. All the clients are in NAT mode, we don't do any bridging.