RouterOS version 6.40.9 has been released in public "bugfix" 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.40.9 (2018-Aug-20 07:46):

MAJOR CHANGES IN v6.40.9:
----------------------
!) security - fixed vulnerabilities CVE-2018-1156, CVE-2018-1157, CVE-2018-1158, CVE-2018-1159;
----------------------

*) certificate - fixed "add-scep" template existence check when signing certificate;
*) defconf - fixed wAP LTE kit default configuration;
*) ethernet - improved large packet handling on ARM devices with wireless;
*) ethernet - removed obsolete slave flag from "/interface vlan" menu;
*) filesystem - fixed NAND memory going into read-only mode;
*) hotspot - fixed user authentication when queue from old session is not removed yet;
*) interface - fixed interface configuration responsiveness;
*) ipsec - fixed policies becoming invalid if added after a disabled policy;
*) ldp - properly load LDP configuration;
*) ppp - fixed "hunged up" grammar to "hung up" within PPP log messages;
*) sfp - hide "sfp-wavelength" parameter for RJ45 transceivers;
*) snmp - added remote CAP count OID for CAPsMAN;
*) supout - added "partitions" section to supout file;
*) tile - fixed Ethernet interfaces becoming unresponsive;
*) tr069-client - fixed unresponsive tr069 service when blackhole route is present;
*) userman - fixed compatibility with PayPal TLS 1.2;
*) userman - improved unique username generation process when adding batch of users;
*) winbox - added missing "dscp" and "clamp-tcp-mss" settings to IPv6 tunnels;
*) winbox - allow to specify full URL in SCEP certificate signing process;
*) winbox - by default specify keepalive timeout value for tunnel type interfaces;
*) winbox - show firmware upgrade message at the bottom of "System/RouterBOARD" menu;
*) winbox - show "scep-url" for certificates;
*) winbox - show "sector-writes" on ARM devices that have such counters;
*) winbox - show "sector-writes" on devices that have such counters;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) wireless - added option to disable PMKID for WPA2;
*) wireless - enable all chains by default on devices without external antennas after configuration reset;
*) wireless - fixed packet processing after removing wireless interface from CAP settings;
*) wireless - improved client "channel-width" detection;
*) wireless - improved Nv2 PtMP performance;
*) wireless - increased stability on hAP ac^2 and cAP ac with legacy data rates;
*) wireless - updated "united-states" regulatory domain information;

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 concrete RouterOS release.

Have been published the CVE?

Thanks you!

3011 and RB750 with MLPPPoE upgraded fine from 6.40.8

Webfig via SSL seems broken. After multiple logins session, the web server seems down and need to be restarted via disable and enable ip service www-ssl.

What is the point of publishing CVE numbers if the vulnerabilities are still private? Hackers can reverse engineer the changes in this version and figure out what the vulnerabilities are and start exploiting them, so there's no point keeping it private once you publish the fix - it only benefits hackers since network admins can't deploy mitigations if they don't know what to mitigate!

I am with Rich on this one, it would be nice to know what these vulnerabilities are since you have patched them.
It is quite a big undertaking to upgrade all of our Mikrotiks as we have thousands of them and SLA's that require we notify all our customers. Knowing what the vulnerabilities are would help us place a priority on upgrading them all.
Some of the recent exploits we were already protected from based on our network restrictions on the IP services, it would be nice to know if that is the case with these.


Edit: Looks like they are going to publish a blog post with more details soon per viewtopic.php?f=21&t=138228&p=681315#p681315

!) security - fixed vulnerabilities CVE-2018-1156, CVE-2018-1157, CVE-2018-1158, CVE-2018-1159;

6.40.8 is vulnerable to this?

Ah jeez , time to ring customers and tell them to brace for another set of sec patches.

Well at least the ansible script to autpatch everything will now come in handy I wrote a while ago.

6.40.8 is vulnerable to this?

yes, check 6.40.9 changelog (or 6.42.7) again, CVE was added afterwards, guess due to coordination? late addition?.

MAJOR CHANGES IN v6.40.9:
----------------------
!) security - fixed vulnerabilities CVE-2018-1156, CVE-2018-1157, CVE-2018-1158, CVE-2018-1159;
----------------------

Definitely knowing if best practices avoid the vulnerabilities beforehand would be great, or at least when will that post be published?

Ah jeez , time to ring customers and tell them to brace for another set of sec patches.

Well at least the ansible script to autpatch everything will now come in handy I wrote a while ago.

mind sharing? been meaning to start one, havent decided how i wanted to do it yet.

CVE details:
https://blog.mikrotik.com/security/secu ... nable.html

5 x 951G-2HnD updated without any problems ... simple sonfiguration.
1 x 1100AHx4 - no problems with update
1 x 1100AHx4 - needed power cycle to start working after "Download&Instal".

If your webserver on the Router is turned off... none of these CVEs are exploitable?
Also the word "authenticated" was used a bunch of times.

If your webserver on the Router is turned off... none of these CVEs are exploitable?
Also the word "authenticated" was used a bunch of times.

1. Yes
2. It means that a RouterOS username and password must be known. The user must log in. Then they can cause www server to crash. Basically this applies only to people with open Webfig interface for Read-only viewing, or such

This version is big catastrophe for me.
Upgraded more than 200 clients from 6.40.8 to 6.40.9 and client started disconnecting after couple seconds again and again.
I am not able to connect to them to made downgrade.
Newer devices (DiscLite) are more touched.
What do you recommend me?
Miroslav

When the clients are disconnecting, make a supout.rif file and email it to support. We will see what causes this. I don't think there are any changes that could cause this, but we will see.

If your webserver on the Router is turned off... none of these CVEs are exploitable?
Also the word "authenticated" was used a bunch of times.

1. Yes
2. It means that a RouterOS username and password must be known. The user must log in. Then they can cause www server to crash. Basically this applies only to people with open Webfig interface for Read-only viewing, or such

Thank you for the clarification!

Here is more info:

https://www.tenable.com/security/research/tra-2018-21

M.

We upgraded all our routers last night. Immediately lost the webserver on one, and today, they lost access to the webserver on another. A reboot brought access back up on them.
Scramble to log back in to all, and turn on SSH to make sure we have a way to get back in them. Looks like there may be a problem hiding in the firmware there?

Suggest that you have additional ways to get into the unit BEFORE you upgrade it.

Hi, great job always!

The fixed vulnerabilities only are involved with webfix at port 80 or also hotspot www service ?

Request to make the security section accessible from the blog menu. Noticing that did raised my blood pressure significantly.

Pressure has dropped by now to more normal levels. I now see that when you scroll down you will find a mention of software and security so it is there but I would love that it would also be reflected in the menu.

In my lab I've been losing the HTTP Server on some devices.

I have support staff that use the web server extensively as we've effectively discontinued using winbox for all management.
Will have to wait for an updated bugfix that hopefully adresses this problem.

@Taylor , I'll see if I can make a blogpost about it though mine is very customized per customer as some of them multiple hops of wireless equipment so updates need to be staged in such a way that master/slave devices get done in a certain pattern.For the most part it's just a dumb ansible w/paramiko script with some device up/down detection.

Hi, great job always!

The fixed vulnerabilities only are involved with webfix at port 80 or also hotspot www service ?

only webfig

When we can see in bugfix tree new bridge capatibilites from current 6.41.xx?

Only when 6.41 is mature and stable enough that it itself becomes bugfix

Regarding

*) hotspot - fixed user authentication when queue from old session is not removed yet;

Can I ask how this would manifest itself - e.g. would it simply be that a user gets prompted for authentication but then it fails even with the correct credentials?

Hi, great job always!

The fixed vulnerabilities only are involved with webfix at port 80 or also hotspot www service ?

only webfig

Hi Normis have you received any supouts of any equipment suffer www/telnet failure after the 6.40.9 ?
Seems to be a random pattern in my lab.I've had devices www services die right after the upgrade and a simple ip service disable/enable correcting it.
Other devices seem to run for a while and then the service just goes unresponsive.

Only when 6.41 is mature and stable enough that it itself becomes bugfix

And hopefully not before the new bridge features have completely replaced the functionality of the old bridge menu.
Right now we are stuck halfway between the old switch method and the new bridge method and this has forced us to keep a number of RB2011 routers where
switch VLAN functionality (at wirespeed) is in use at the bugfix release, and it would be bad when there would be no such release anymore.
Maybe introduce a new release branch at that time? (which keeps classic masterport/switch function until new bridge supports VLAN hw offload)

Hi Normis have you received any supouts of any equipment suffer www/telnet failure after the 6.40.9 ?

.
I've sent sup-out to support and received reply:

... it seems that we managed to reproduce this problem. We will work on a fix for it and release patched RouterOS version as soon as possible. Please upgrade when you see fix for WWW service becoming unavailable in RouterOS upcoming releases changelog.

.
Description of my case: on hAP ac2 webfig service stopped responding, www service was consuming 100% of a CPU core (RB still remained responsive as it has 4 CPU cores) and disabling www service failed with message action timed out - try again, if error continues contact MikroTik.

And hopefully not before the new bridge features have completely replaced the functionality of the old bridge menu.
Right now we are stuck halfway between the old switch method and the new bridge method and this has forced us to keep a number of RB2011 routers where
switch VLAN functionality (at wirespeed) is in use at the bugfix release, and it would be bad when there would be no such release anymore.
Maybe introduce a new release branch at that time? (which keeps classic masterport/switch function until new bridge supports VLAN hw offload)

Can't you simply use the bridge without VLAN filtering, and continue to use the switch VLAN? I would think the bridge without VLAN filtering would act very similarly to the master port function and should maintain the hardware offload.

Can't you simply use the bridge without VLAN filtering, and continue to use the switch VLAN?

Indeed. When I upgraded my VLAN infested RB951G from 6.40.x (whatever x was at the time 6.41 became "current") to 6.41, the upgrade process changed bridge config to the new style while it didn't touch VLAN config on switch chip. The same setup happily humms running 6.42.7 and is fully HW offloaded.

Yes, but it is unclear if you can re-create this configuration because masterport is no longer defined.
And also if it will still be wirespeed with the bridge interface between it.
So I hope we will get the old functionality of the switch menu (defining VLANs and setting tagged- and untagged ports) inside the new bridge menu with hw accel.
On one RB2011 I changed to new config and it is no longer accelerated! (I use ports 2-5+SFP for wirespeed gigabit and ports 6-10 for 100 Mbit individual link ports)

Yes, but it is unclear if you can re-create this configuration because masterport is no longer defined.
And also if it will still be wirespeed with the bridge interface between it.

Yes to both, I am nearly 100% sure.

In the new setup if you make a bridge and add ports ether2-ether10 to that bridge, it should be identical in operation to an older config with a 3,4,5 being set for a master-port of 2 and 7-10 having a master port of 6, and then connecting master ports ether2 and ether6 with a bridge.

On one RB2011 I changed to new config and it is no longer accelerated! (I use ports 2-5+SFP for wirespeed gigabit and ports 6-10 for 100 Mbit individual link ports)

If you have bridge VLAN filtering disabled and you it is no longer accelerated at 6.41+, it is because of spanning tree being turned on. Turn off spanning tree on the bridge. We had that issue with an RB3011.

There is no need to stay on bugfix indefinitely, you can move to the new version, just as long as you continue to use the switch VLANs, and have bridge VLAN filtering disabled and STP off, it should act the same as before with full hardware acceleration.

On one RB2011 I changed to new config and it is no longer accelerated! (I use ports 2-5+SFP for wirespeed gigabit and ports 6-10 for 100 Mbit individual link ports)

If you have bridge VLAN filtering disabled and you it is no longer accelerated at 6.41+, it is because of spanning tree being turned on. Turn off spanning tree on the bridge. We had that issue with an RB3011.

There is no difference between spanning tree off or on. It is off on my RB2011 but it still does not accellerate VLAN switching as it did before 6.41 with the switch setup.
I don't understand why bridge with VLAN filtering configuration cannot use the same hardware features as the old masterport/switch configuration did.

There is no need to stay on bugfix indefinitely, you can move to the new version, just as long as you continue to use the switch VLANs, and have bridge VLAN filtering disabled and STP off, it should act the same as before with full hardware acceleration.

There still is a bridge between it that I did not have in the old config. My old config had only a master-port to which VLAN subinterfaces were directly connected, no
bridge defined at all. When I update such a config to newer RouterOS (I tried that!) it will create a bridge containing all the ports that had master-port set and this is
an extra layer that I did not have before. You are right that it does not touch the switch setup but it is now unclear what layers the data has to go through.
It would be better when the switch config is translated into bridge VLAN filter config, and it is accellerated.
The switch menu can then be removed.

As you say, ideally the switch menu VLAN configuration should be replaced by the VLAN-aware bridge so if a port has hardware offload enabled this is automatically translated into the necessary switch VLAN configuration.

Meantime, it should be possible to use the switch chip with a non-VLAN aware bridge - pre-6.41 the name of the master port is used for two things, both the physical port and the interface name, e.g.
with 6.41+ the 'master port' has a different name, e.g.
so rather than attaching the CPU-to-switchchip VLANs to ether2 attach them to bridge1 instead.

There still is a bridge between it that I did not have in the old config. My old config had only a master-port to which VLAN subinterfaces were directly connected, no
bridge defined at all. When I update such a config to newer RouterOS (I tried that!) it will create a bridge containing all the ports that had master-port set and this is
an extra layer that I did not have before. You are right that it does not touch the switch setup but it is now unclear what layers the data has to go through.

I believe I can explain. I'm going to assume that previously you had eth2 as a master port for eth3-5 and eth6 as a master port for 7-10.
Now I presume you have two bridges, bridge1 for eth 2-5 and bridge2 for 6-10? That new setup is very similar to the old one, with one change. The exactly equivalent old setup would have eth2 as a master port for eth3-5 and eth6 as a master port for 7-10, but then also have two bridges, bridge1 and bridge2, each with one port only, bridge1 having ether2 as its only port and bridge2 only having ether6 as its only port. If you took your old setup on 6.40 and earlier and added two bridges, bridge1 and bridge2, and added the master port as the only bridge member, that would be the equivalent. Making this change does not greatly alter the behavior of the device.

It would be better when the switch config is translated into bridge VLAN filter config, and it is accellerated.
The switch menu can then be removed.

Yes, I agree completely.

We need a fast update for web service that is getting down...

Now I presume you have two bridges, bridge1 for eth 2-5 and bridge2 for 6-10?

No, I have no bridges at all!
The ports below 5 are used in a LAN config and ports 6-10 are individually used for PtP links to other routers in the network.

No, I have no bridges at all!

I am confused. You said when you upgraded the device it created a bridge. Now you say you have no bridges on the upgraded device. Which is it?

We need a fast update for web service that is getting down...

i didnt find any way to restart the service without reboot, isnt it?

I can see problem with web server over https. After file download it gets unaccesible.
Anyway I've enabled http over CLI and that works.

I was told by MikroTik support that the OSPFv3 fix (improved link local flooding from 6.43rc) was supposed to be included in the next bugfix and current release. However I do not see the ospf fix in the changelog. Is it there and it the changelog didn't mention it, or was it not included for some reason? We were hoping for this to be included since without it our OSPFv3 is very unstable, if there is an outage it often will not recover properly.

Fix will be included in next version.

Fix will be included in next version.

OK, thanks!

I agree that the way the patch notes were written made it look way more urgent than it was.
Compared to how the WinBox vulnerability was mentioned in v6.40.8 [bugfix], it makes it looks like the CVE vulnerabilities were much more important.

Changing the way you announce vulnerabilities in patch notes is ok, but you scared everyone by posting the suddenly very huge vulnerability warning with no information in the patch notes.
Writing something simple like you used to do is better. For example:
"!) Webfig: Fixed vulnerabilities allowing a logged in user (even read-only user) to crash the router."

Then after the blog entry was posted, you could add the CVE id numbers and links to the blog entry in the opening post.

I can't explain this:
I have this code in ipv4 mangle: I have queue tree with one parent (global) and the QoS_4 and 5 as childs.
When I open ~20tabs in firefox i have average ~30s page load.

Now i put at the end (if i add it before i have the same result) of the code this code: No i have normal page load average ~10-15ms.

The above code also work perfect without packet mark in download.
The above code also work if i have disable the QoS-DW in tree.
The above code also work if i mark something that its not present in tree.

The problem its not appear if i write the code like that (with chain postrouting):
1. I start with packet only marks.
2. I make jumps for connections with nomark and packets for mark connections with out-interface.
3. In jump connections, I mark them with no passthrough and nothing in out-interface.
4. In jump packet, I mark them with no passthrough and nothing in out-interface.

Where is the problem with the first solution?
Is it some bug;

I can't explain this:
I have this code in ipv4 mangle:

Is your problem new for 6.40.9? If not, then please do not discuss it in this topic but make your own new topic.

I can't explain this:
I have this code in ipv4 mangle:

Is your problem new for 6.40.9? If not, then please do not discuss it in this topic but make your own new topic.

I dont know if the problem is new or old.
I check it only in v6.40.9 [bugfix]

Hi.

I tried to downgrade an RB750GL from 6.42.7 to 6.40.9. After reboot, I lost connectivity to router. No winbox, no ssh, no mac-telnet, no nothing... No ping reply, no DHCP-serving on any ports.
I must hard reset to wipe off my config. (Probably the hardware offloaded bridge...)
After hard reset, I can mac-telnet, downgrade (to 6.40.6, because I have backup at this version), and restore old config without bridge, with only master/slave switching on ports.
Then I can upgrade to 6.40.9 successfully.

So avoid to downgrade with bridge hw-offload active, the result may be full loss of connectivity.

Best regards: CsXen

Cant downgrade a CCR-1036-8G-S2+ EM from 6.43 to 6.40.9.

Currently on 6.43. Reset config. Then upload os. In winbox->package Downgrade. After reboot Router Shows "starting Services" and is not accessible. Has to be netinstalled.

This is written in the 6.41 release notes. To downgrade across the 6.40-6.41 border you need to netinstall and reconfigure or load a backup you made on 6.40 or slightly before.

You called 6.40.X versions as "Long-Term". How long-term it will be? One year? 2 years ?

Just noticed on this version that RB3011 display screen no longer scrolls during bandwidth monitor. Has anyone else had touch screen issue where its locked up on 6.40.9 ? It was working in earlier versions of 6.40.x

You called 6.40.X versions as "Long-Term". How long-term it will be? One year? 2 years ?

+1

Is it just a name change, or a serious strategy change?
Please MT, portrait clearly what is in store for the future with regards to config-stability.

Official info about this would be greatly appreciated.

Possible bug:
I have installed a fresh CHR with 6.40.9; the SIP helper port config is completely missing in webfig. It is present (and was enabled by default) in the ROS cli.

Anyone running 6.40.9 + the 3.41 firmware on a CCR-1072 ?
If so, have you come across any issues (other than the webserver issue).

New version 6.42.9 has been released in long-term RouterOS channel:

viewtopic.php?f=21&t=139847