We are experiencing a really strange problem:
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 (188.8.131.52), 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
Thanks in advance!
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.
On the Mik set the L2MTU to 1600.
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 (184.108.40.206).
Hi ValWeb – this probably is NOT a solution, but I’d recommend going to 220.127.116.11 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 18.104.22.168 (or better yet, the new 4.7.1)
thank you for the comment; we are moving all apparatus on 22.214.171.124 even if in the document where fixed problems are highlighted there was not any (similar) information related possible problem in this direction.
Did upgrading to 4.7.1 solve this issue?
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).
drop me please your support ticket ID!