we changed the MTU value to 1600 on two ePMP 3000 and, after the asked reboot, the APs became inaccessible. They do not answer on the recovery address (168.254.1.1), they do not answer to any ping. We also tried to reset it both by exploiting the powering cycle (to avoid dismount it from the tower) and even using the reset button (when we reached the tower) but no one of them worked to reset the APs.
The really strange thing is that the APs seems switched on (see attached files) even if they are not reachable (and of course they detach all SMs).
Any idea/suggestion? The system release on both APs is 4.7.0
I’ve briefly checked MTU change on E3K. And on 4.7.0 it has just came back from the reboot. It stays accessible both via management vlan and via backdoor.
Did you get the unit on the bench? You can connect to Ethernet and listen with tcpdump if it sends something. It can give a clue on what condition it is in.
Also did you use HTTPS to access the GUI? In case yes after defaulting the unit you have to use HTTP to connect via backdoor.
Sometimes configuration change, upgrade or reboot coincide with some other issues.
thank you for the feedback; we actually put on the bench one E3K and we were able to access again to it after an hard reset (by pushing the button for 20s); maybe on the tower was not made in the right way.
The strange thing it that configuration can coincide with some other issues, but we observe the same behaviour on another E3K (inaccessible after changing MTU value and reboot), while on others E3K and E3K-L (all with 4.7.0) the modification worked well.
We can try to listen with tcpdump on the other E3K currently not working to understand what happens.
thank you for the feedback; we can try, even if we noticed that the E3K does not answer even when connecting directly with a cable form a pc on the recovery address (168.254.1.1).
Hi ValWeb – this probably is NOT a solution, but I’d recommend going to 4.7.0.1 on everything. 4.7.0 had a bunch of small bugs, and all known bugs with known solutions we all fixed in .0.1
So, basically everybody running 4.7.0 should upgrade to the latest 4.7.0.1 (or better yet, the new 4.7.1)
thank you for the comment; we are moving all apparatus on 4.7.0.1 even if in the document where fixed problems are highlighted there was not any (similar) information related possible problem in this direction.
not yet moved on 4.7.1 as suggested by Cambium Support; from our point of view a random “crash” (since it has happen on some radios only with same FW version) is hard to discover, but I hope that Cambium is investigating on the problem (if is only a SW problem).
