Well, since 60GHz is limited to ~2.5km (at least on Earth at sea level, maybe a bit more in the mountains), then the trip wouldn't be so "looooong" 
One can probably get there on foot, do the downgrade and walk back all within 1 hour, even get a beer in the process (schedule the trip to the end of work day).
Now, I am not defending Mikrotik, I was just about to update my few WW links when I saw this...
Partly true. The link is just a few hundred meters - but the customer ist about 300km away
Well, I think it is not unreasonable for a customer to expect that upgrading from 7.19.3 (stable) to 7.19.4 (stable) would not result in such major breakage...
On the other hand, it has happened before. 60G is apparently not on the main test suite.
1 Like
Yes, I can see the problem there 
When I do updates to remote equipment, no matter how trivial they might be, I always try to have someone with a laptop relatively close, so I can ask them to connect laptop to ethernet port and to the Internet via phone tethering, so I can access and fix the router remotely (RustDesk is my best friend now). Even customers can do that during a "loooooooooooong" phone call, especially if their job is depending on it... well sometimes it's better just to hit the road
Of course in such setups it is likely that the "remote" used that link for internet connectivity, and now has no internet at all, so such solutions are difficult to apply.
Looking back it is easy to say "you should always update the local side first" so he could then downgrade it after losing the link, but again it was an upgrade from stable to stable so what would you expect to happen?
At least now there is another admin who won't upgrade just for the sake of upgrading anymore...
Well.... no risk, no fun And I thought that this update is fail-save because just one sub-release inside a "stable" tree..... however. Maybe someone has an idea for a work-around - I tried playing with 60G settings on the master, but up to now, no success. And by the way: other 60G devices have no problem with 7.19.4 here - only this nRay.
You could ask the mikrotik support via a ticket. They know what mistake they made, so maybe they know a possible workaround.
Are you kidding? They have a huge testing infrastructure. I have proof. It's the users on the forum...
1 Like
Well, in the past when we accused them of not testing, e.g. when upgrading would cause the storage to run out on certain devices, we got the reply that all releases were tested on all models. But it seemed to infer that it only was a test of the default configuration being upgraded to the next higher version.
In this case it could be expected that it would include a test of a pair of devices linked together (as that is the default configuration of the 60G devices), but apparently this wasn't tested.
7.20beta9 fixes the issue.
but no mention of it in the 7.20rc1 release notes from 29th August ?
It is working, I've still tried it.
Everybody knows but noone care...even MT
I fell victim to this bug..upgraded a 1km link consisting of 2x nRAYs...link went crazy and disconnected all the time.
Upgraded to 7.19.6 which according to the changelog claims to have fixed it, and at least it was able to connect, but I struggled with low signal levels/rates and disconnects all the time. On autochannel it also picked a channel already used in another device in the same tower..clearly present in /scan.
So I downgraded to 7.19.1 and stability was re-gained.
I have several Cube SAs running on 7.19.4 so I wonder if this is all an arm64 bug?
Before filing a support ticket with MT I just wanted to check with you guys, any of you that found that 7.19.6 has NOT rectified the issue?
If you observe things have not been resolved for your situation, it might anyhow be worthwhile to contact support about it providing supout.rif.
Maybe they missed some conditions which are applicable for your situation.
Thank you holvoetn!
Good idea, in order to not spam down MT support I just wanted to check with the community here 