I had read that too. With the latest firmwares, my DFS detects went from zero to zero . Even if it actually got worse, which it might, I think the problem is still at least an order of magnitude worse with MT devices regarding rate of false positives.
My setups are almost entirely mixed-vendor. I do have the direct comparison that way.
We have several installations with both makes of AP and with those 6.1.8 and 8.5.8 releases in some locations the AP completely failed (only hunting for RADAR free channels which it never found), on others it was sort of okay but switched every couple of hours (which did not happen before the change) and others are unaffected. We rolled back to 6.1.7 and 8.5.7
With MikroTik it was always like that. We are now running 6.43.7 on the MikroTik APs.
Those installations are 40-220m above ground level and use sector antennas.
CCR-1009-PC : 6.43.4 → 6.43.12 (OS and bootloader) : No issues
RB3011: 6.42.4 → 6.43.12 (OS and bootloader): 1 CPU @ 100%
RB2011: 6.41.2 → 6.43.12 (OS and bootloader): No issues
RB 750Gr3/hEX 6.43.1 → 6.43.12 (OS and bootloader): No issues
RB941-ND2/hAP lite 6.43.7 → 6.43.12 (OS and botloader): dowloading but not installing. 7,0 MB free (before reboot around 400K free), after deleting really everything and 7.8mb free it worked.
I’ve got IPSec problem after upgrading to v6.43.12. I use RB1100 devices, with IPSec vpn. The ipsec peers are configured in the IP->IPSec->Peers menu. The peer profile is sha512/aes256/modp8192 in both side, and the auth method is rsa signature. After upgrading to 6.43.12 in the log I see the following lines: x.x.x.x failed to get valid proposal, no suitable proposal found.
The configuration not changed, only the software were upgraded.
I had a similar issue with my GRE tunneln + IPSec but also related to restart. The issue was that the router rebooted faster then the timeout value and then I got the same issues in the log. As said above Flush SA works fine but I also now disable the GRE interfaces before upgrade or reboot and have lowered the timeout value.
Now I’m using gre+IPSec and it’s working, but I not need gre, I want to use simple IPSec connection, and it’s not working. I tried with 6.43.8 and working well, but in the version 6.43.12 no proposal found.
My guess is you need to flush SA on the remote endpoint. All connections that I connect to via GRE tunnel I can also connect to via SSH without the GRe tunnel so I can troubleshoot and in this case Flush SA.
Still having the sameOSPFproblem that we first encountered in 6.43.8:
When WDS drops and reestablishes, OSPF updates on the local machine, but doesn’t seem to propagate to any of its neighbors on other interfaces. Manually disabling and re-enabling the OSPF network, or manually disabling and enabling the wireless interface, immediately fixes the problem.
Update: Changing the OSPF network type of the interface in question to “point-to-point” doesn’t makes any difference.
I have. Apparently it isn’t easily reproduced. I had hoped that they would have fixed the problem since 6.43.8, but we just upgraded both ends of the link to 6.43.12, and the problem is still there. We have dozens of such links in our network, and this is the only one we have found to have this problem with OSPF.
Nice, so this actually IS quite serious security hole that have been silently patched. Proper changelog should have been something like:
*) winbox - fixed vulnerability allowing access to devices behind router with open winbox port