Recently we encountered this issue on PTP300 running 4-00 firmware.
Reterminated RJ45 connectors (STP Cat5 cables less than 100m) from top to bottom and still occurs. Tried to erase, zeroise config/settings until it can no longer be pinged using assigned or default ip. The system initializes properly (base on 10 led flashes), then the eth port never came back.
Have the device settled for some time then tested again, and this time again its ok. 2-units of the same case were experienced. The other turned into another issue and that is the Invalid Mac Address error where all octets of the MAC are set to “0”. Is this doable locally?
Another issue on this is running SNMP tool on the device. Currently using The Dude by Mikrotik, and using custom key string base on client preference. When enabled and past some time the device ethernet port dies as it cannot be detected by the SNMP management tool. Shutting down the SNMP tool allows the device to go up again. Take note that we experienced the same issue for 3 different units already and to make the system useable we have to turn-off snmp on device config.
Has anyone experienced the same or similar cases?
dont mix dude with motorola ptp.
We tried to test the dude, everything was going fine until one day one ptp600 starts rebooting every couple of minutes…
we start thinking and remembered that the person testing the dude reinstaled due to some strange behavior the day before. Inmediatly shut down de dude server and the problem was gone.
I didnt even try to investigate what happend, just told the people in the office: “dont want to hear again about that software…we are not going to risk our network for some free software!”
Hi Gerry
I havn’t heard of an issue simular to what you are describing
The “10 ethernet flashes” would indicate to me that the unit is booting into recovery mode
From the manual
"To enter recovery mode manually, press the Recovery switch located on the underside of
the PIDU while applying mains power (Figure 7-25), hold the Recovery switch in for
between 10 and 20 seconds, then release it. The Ethernet LED will double-flash 10 times
at power up."
The unit will also go into recovery mode if the ethernet cable between the ODU and the PIDU is not wired correctly or there is a short.
You can obtain a free cable tester from us by visiting this link -
http://www.cambiumnetworks.com/support/ … tester.php
This will help you troubleshoot your cabling
If you are in recovery mode you can access the link on 169.254.1.1
You must be on the same network, and not through a router, as the unit will not have a default router set.
If you need any further help, please contact tech support
Regards
Julian
I had the exact same issue. Cost me most of my weekend.
We run quote a large licensed network with a few UBNT links for less important stuff / routed with Mikrotik running MPLS, running the Dude and loving it, its a very powerful tool.
Anyway on an isolated customer network we started to have issues with a Trango Apex link so I decided to run up the dude to see what was going on with the Trango (powerbridge currently doing its job) Ayway this network has 2 x 54500’s and 2 58500’s.
The dude was running and SNMP was turned on all the Motos, anyway on the last link as soon as I turned on SNMP it went down stopped responding to pings. Link is running 58500-04-00 thought the old girl didnt like a reboot after 4 years. Anyway I ended up going to site and replaced the 58500 and was happy that my link was restored. Turned on SNMP and bam, it went off.
So Ive got the first (removed) 58500 testing on the bench, it responded to pings straight away when on the test network away from the probing dude. However I soon noticed it stop responding. Then I did a recovery / now its running in install mode. The current state of the unit responds to 200 x 32 byte pings drops 10 the responds to 200 etc. so wondering if it is restarting itself in install mode once it cycles though or something.
Its a pretty nasty bug, need new firmware ASAP… have logged support case.
Someone said not to use the dude that’s a load of rubbish they obviously don’t understand SNMP.