Disable the Maestro management and see if the same disconnects happen.
Thanks, we tried that but the issue came up again today, even with cnMaestro agent disabled on both sides.
We did discover something interesting, we can ping it if we keep the MTU within 514 bytes L2 from both local subnet and from far away (such as my workstation) while 515 bytes chokes and gives no responses.
And the same test works both over RF over Ethernet.
But since web interface doesn't come up, it's probably not just the MTU setting (that ought to lead the webserver to try to send smaller packets as well), but some other issue preventing packets over a certain size from getting processed. So web server still tries to push 1500 byte packets, and those can't make it through.
So something in the radio is severely limiting the MTU for the in-band mgmt... but not for normal traffic being bridged.
One more thing we were going to try would be reversing rolls on the radios... swapping master and slave sides. It's a long shot, but something we haven't tried yet.
Update, we swapped rolls and now the new master side has had it's mgmt locked out again. So it does appear to follow the master side of the link... or it could be that it's related to access usage, as we typically log in to the master side more often then the slave side. The next test is to downgrade firmware. We've never seen this with earlier firmware so we are betting $$ that this issue will disappear as we have other 670's with earlier firmware and no issues.
We're now experiencing watch dog resets and this mgmt issue. We're really not happy with this new 670 firmware.
Same problem on our PTP670, master and slave...after disabling cnamestro on Master for now it looks like problem are gone, unfortunately for now we cannot access slave, because it must be rebooted, but we must go on site for that. :(