RouterOS version 6.43.16 has been released in public "long-term" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.43.16 (2019-May-14 11:40):

Changes in this release:

*) w60g - fixed memory leak (introduced in v6.43.15);

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

Please keep this forum topic strictly related to this specific RouterOS release.

Thank you for the prompt fix.

No issues on CCR1016s, CRS125s, RB951Gs, SXT5ACs, wAP60Gs, CHRs.

Been up a hour all good.

Cheers!

Other models don't need update from 6.43.15?

Other models don't need update from 6.43.15?

It is a w60g only fix so if you don't have it, you don't need it

Fast fix, thanks MikroTik.

Skip this release because contain fixes just for one particular model.

When updating ~30 systems, all with identical configurations running ROS 6.42.3 on 951G devices, and using an identical script to perform the update:
ROS update was successful.
Firmware update was successful.

However, on only 2 of the 30 completed updates, after the required reboot following the firmware update, all of the scheduled tasks and all of the scripts were gone (as viewed using WinBox). As far as could be determined, the remainder of the configuration was intact and operational.

Anyone seen this problem? (have another 1300+ identical systems to update....)

Hi,
I wanted to upgrade my wAP LTE KIT from 6.42.9 to the latest bugfix, however the critical feature I use - LTE Passtrough - seems to work differently and I wonder if this is intended, because the new way of working breaks the functionality for me.

Setup is as following:
wAP LTE KIT ----eth---- Juniper SRX

wAP has LTE Passtrough feature configured and Juniper SRX is a DHCP client.
On 6.42.9 everything works excellent.

After the upgrade, Juniper exchanges DHCP packets with Mikrotik, however the result is that Mikrotik says:
"data assigned xx.x.x.x to xx:xx:xx:xx:xx:xx", but Juniper does not configure the IP address.

Can anyone explain me what exactly changed? I saw in the changelog information about /32, but I see it's not all.
I see the gateway for example is being sent different, as well the server-id.

I would much appreciate any information so I can further troubleshoot the issue.

are we getting long-term version with this fix?

Ditto on the recent Linux DOS vulnerabilities update - will Long-Term receive it and when. If not, please provide recommended Firewall filter rules. Thank you.

Ditto on the recent Linux DOS vulnerabilities update - will Long-Term receive it and when. If not, please provide recommended Firewall filter rules. Thank you.

The advisory linked to in the blog post suggest blocking TCP traffik with a low MSS, but doesn't mention what this "low MSS" is.
So my guess would be something like this: But this is just a guess, I would wait for MikroTik's official reply.
As mentioned in the advisory, this might affect normal operations if legit TCP traffik is using "low MSS".

Ditto on the recent Linux DOS vulnerabilities update - will Long-Term receive it and when. If not, please provide recommended Firewall filter rules. Thank you.

The advisory linked to in the blog post suggest blocking TCP traffik with a low MSS, but doesn't mention what this "low MSS" is.
So my guess would be something like this:

Code: Select all

/ip firewall raw
add action=drop chain=prerouting protocol=tcp tcp-mss=0-1000

But this is just a guess, I would wait for MikroTik's official reply.
As mentioned in the advisory, this might affect normal operations if legit TCP traffik is using "low MSS".

The iptables examples consider 1:500 as small

iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP

https://github.com/Netflix/security-bul ... 019-001.md

https://github.com/Netflix/security-bul ... tables.txt

... please provide recommended Firewall filter rules.

Please see also:
viewtopic.php?f=2&t=149425&hilit=CVE+2019+11477#p735645