I have noticed over the past few days, a handful of my radios across multiple sites are picking up orange sensors on The Dude, marking an issue with device RSSI.
When logging into the radios, they are reporting the RSSI value as blank. This seems to be resolved with a /system reboot, but I don’t want to have to cause downtime unnecessarily.
I don't know, but you could try - instead of rebooting - to disable, wait a few seconds and re-enable the 60 GHz interface, at lest in theory the link would switch to the 5 GHz one, and - still in theory - all the users should perceive would be a temporary (a few seconds) slowing down of the connection.
It sounds strange that with the original (or at least not recently changed) version of RoS the behaviour you report has started "out of the blue".
I also have an ongoing issue with 60ay devices randomly stopping reporting RSSI, with it appearing a zero / blank in Winbox / CLI / SNMP / Dude, however 60ad devices (Cube 60G, wAP 60G, LHG 60G) seem fine.
Support suggested upgrading to ROS v7, although why newly manufacturered devices are being shipped with v6 is anyones guess, especially as I’ve had around 10% of the devices lock up during the v6 → v7 upgrade and require a power cycle. Luckily these tests were at a site with managed PoE switches and redundant links but it doesn’t bode well for other remote sites which do not have these.
Having tried 7.12.1 (the version offered during the upgrade) and 7.18.2 the problem persists, as it does with 6.49.18. I suspect something in the 60G radio driver gets confused as the RSSI value disappearing seems to coincide with a change in either of the PHY rate or MCS reported.
The RSSI will sometimes reappear, again with a change in the PHY rate or MCS, after some random interval - anything from a few hours to days. Disabling and reenabling the w60g interface does immediately restore the missing RSSI value.