v6.43.12 [stable] is released!

That’s not version specific. Anyway… Use:

ping interface=[ / interface get $interface name ] address=8.8.8.8 interval=00:00:05

after reboot - working. x86.

I had read that too. With the latest firmwares, my DFS detects went from zero to zero :smiley: . 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.

Hi
can confirm the same on my side.

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.



Yours

Upgraded from 6.43.11 → 6.43.12
using dude to push the packages on

CCR1009-8G-1S (2x ipsec/l2tp site-to-site, dhcpd)
CRS125-24G-1S
RB1100
RB962UiGS-5HacT2HnT (10pc)
RB951
RB750GL
RB2011UAS-RM
CHR running dude (CHR running in VirtualBox on OSX)

without any issues

Solved the problem by uninstalling The Dude, deleting all related files and reinstalling again.

my dude can’t work the dude client said connection time out

FYI
RouterOS 6.43.12
Routerboard 6.43.12
Dude Server 6.43.12
Dude Client 6.43.12

Right-click and “Run as Administrator” should resolve this.

Hello,

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.

Andras

Try flush installed SA-s

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.

I tried, it was the first step when I detected the problem…

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.

I flushed both endpoints…

Still having the same OSPF problem 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.

Please write to support@mikrotik.com

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

See http://forum.mikrotik.com/t/security-issue-when-winbox-exposed/127915/1 and https://medium.com/tenable-techblog/mikrotik-firewall-nat-bypass-b8d46398bf24 for details.
We have security blog and all what we get is… silence,nothing,
Last blog post is from 9th Oct, 2018.
Lovely security transparency, right here.