RouterOS version 6.49.8 has been released in the "v6 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.49.8 (2023-Jul-19 13:40):

!) ipv6 - fixed DNS server processing by IPv6/ND services (CVE-2023-32154);
*) console - updated copyright notice;
*) defconf - fixed invalid default password setting after configuration reset for 60GHz interface (introduced in v6.49.5);
*) firewall - fixed IRC NAT helper (CVE-2022-2663);
*) hotspot - improved stability when receiving bogus packets;
*) smb - fixed SMB2 file list reporting;

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 a router is not working as suspected or after some problem has appeared on the device

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

So far so good on roll out on test devices/networks, no issues so far, after some more testing will start slowly rolling out to main network. Glad there was an update, I have many mipsbe devices that really can't run V7 in production.

Updated a RB750r2 (was 6.49.6) and RB750Gr3 (was 6.49.7) to 6.49.8 without issues noted so far. Neither of those is critical.
I will update my RB4011 (currently 6.49.6) tonight when I'm home. This one is critical to my operation.

Updated RB4011 from 6.49.7 . No problems so far. Ipv6 is working like before using DHCPV6 client for prefix and adress, ND and DHCPv6 server for transmitting DNS.servers. Router advertisements on in IPV6 settings.

Thank you for the security fix.

Thanks for this update.

Upgraded successfully all my devices.

Regards.

Anyone else having issue with the date/time settings after upgrade?
My was 12h off. I had to manually set my time.
Then Enabled SNTP and added se.pool.ntp.org as servers.

MT devices don't have RTC built in, so ROS has to "invent" an approximation to current time when it boots. After initial boot (from factory or after netinstall), ROS doesn't have any better clue so it sets time to 1970-01-01 00:00:00. After a "normal" reboot, ROS takes time stamp of some of recent files and starts from there. Since everybody wants small number of writes to built-in storage, this means that timestamp can be old (from minutes to hours).

So when there's a mechanism which retrieves precise time stamps (either NTP client or cloud time) and ROS has to step time (by more than some margin, with normal NTP client this is when time difference exceeds few tens of seconds), there's a log entry - because stepping time means discontinuity in timestamps (e.g. of log entries). Seeing those in log happening a short time period after device reboot is thus normal. However, if this happens regularly or after longer uptime, this might indicate some kind of problem.

And yes, configuring and enabling (S)NTP client on ROS device is the right thing to do.

MT devices don't have RTC built in, so ROS has to "invent" an approximation to current time when it boots. After initial boot (from factory or after netinstall), ROS doesn't have any better clue so it sets time to 1970-01-01 00:00:00. After a "normal" reboot, ROS takes time stamp of some of recent files and starts from there. Since everybody wants small number of writes to built-in storage, this means that timestamp can be old (from minutes to hours).

So when there's a mechanism which retrieves precise time stamps (either NTP client or cloud time) and ROS has to step time (by more than some margin, with normal NTP client this is when time difference exceeds few tens of seconds), there's a log entry - because stepping time means discontinuity in timestamps (e.g. of log entries). Seeing those in log happening a short time period after device reboot is thus normal. However, if this happens regularly or after longer uptime, this might indicate some kind of problem.

And yes, configuring and enabling (S)NTP client on ROS device is the right thing to do.

Thank you!

Anyone else having issue with the date/time settings after upgrade?
My was 12h off. I had to manually set my time.
Then Enabled SNTP and added se.pool.ntp.org as servers.

I not noticed that. All is working fine.

Regards.

On my ROS 7.9.1 driven RB951G I got single

may/22 12:48:52 system,critical,info ntp change time May/22/2023 12:48:52 => May/22/2023 19:21:20

about 16 seconds after booting. Seems like the log entry timestamp is the unstepped value ... The time step of 6,5 hours is substantial. Another device had time step of almost 16 hours.

I think it's much better to see such a time step early after boot than to have time offset dragging for days (or forever if device doesn't get any time update from any source).

[edit]
I'm looking at one of ROS 6.49.8 driven devices. There I don't see similar message. However I'm suspecting that time step does happen as well, there's a timestamp discontinuity during later stages of boot procedure, amounting to "only" 1,5 minutes ...

Hi Mikrotik,

in v6.48.9

/ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
DST-ADDRESS GATEWAY DISTANCE
0 ADb 2001:4:112::/48 fe80::a05:e2ff:fe07:7... 20
1 Db 2001:4:112::/48 fe80::a05:e2ff:fe07:7... 20
2 ADb 2001:500:3::/48 fe80::6e3b:6bff:feec:... 20
3 Db 2001:500:3::/48 fe80::6e3b:6bff:feec:... 20

in v7.10rc
MikroTik-BGP] > /ipv6/route/print
Flags: D - dynamic; X - disabled, I - inactive, A - active;
c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, g - slaac, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp
DST-ADDRESS GATEWAY DISTANCE
DAb 2001::/32 2001:f20:f000:3815:4:... 20
DAb 2001:4:112::/48 2001:f20:f000:3815:4:... 20
DAb 2001:200::/32 2001:f20:f000:3815:4:... 20
DAb 2001:200:900::/40 2001:f20:f000:3815:4:... 20
DAb 2001:200:e00::/40 2001:f20:f000:3815:4:... 20
[Q quit|D dump|down]


i have reply from support regarding this issue, with v6 i have to filter it to make global as preferred.

Can u make v6 also choose global as preference please,
because it's not common way with other routers, it's make our partners with other router asking why?
please make it standard/ common way without adding any additional filter

thx

Version 6 will only receive critical and security fixes. There are no plans to add general behavior adjustments or new features to it.

INFO ONLY:

MS Win 10.0.19045.3086
sigcheck -s -e -u -c .

Sigcheck v2.90 - File version and signature viewer
Copyright (C) 2004-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

EXPIRED = A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file

Publisher, Date, Verified, Path
Mikrotikls SIA, 22.05.2023 15:44, EXPIRED, .\routeros\6.49.8\btest.exe
Mikrotikls SIA, 05.01.2012 20:21, EXPIRED, .\routeros\6.49.8\dude-install-6.49.8.exe
Mikrotikls SIA, 22.05.2023 15:45, EXPIRED, .\routeros\6.49.8\flashfig.exe
Mikrotikls SIA, 22.05.2023 15:44, EXPIRED, .\routeros\6.49.8\unpacked\netinstall.exe
Mikrotikls SIA, 01.01.1970 02:00, EXPIRED, .\routeros\6.49.8\unpacked\netinstall64.exe

Mikrotikls SIA, 23.05.2023 07:57, EXPIRED, .\routeros\6.48.7\btest.exe
Mikrotikls SIA, 05.01.2012 20:21, EXPIRED, .\routeros\6.48.7\dude-install-6.48.7.exe
Mikrotikls SIA, 23.05.2023 07:57, EXPIRED, .\routeros\6.48.7\flashfig.exe
Mikrotikls SIA, 23.05.2023 07:56, EXPIRED, .\routeros\6.48.7\unpacked\netinstall.exe
Mikrotikls SIA, 01.01.1970 02:00, EXPIRED, .\routeros\6.48.7\unpacked\netinstall64.exe

EDIT: formatting changed to not appear as an alert and appear more as an info

A file signed in the past, with a certificate that was valid at the time, but has now expired, does not mean that the file is corrupted or that the signature is forged...

You are creating Alerts for nothing...

is this version include the fix of #[SUP-92244] regarding max active session of the dude ?

thank you

P

ROS 6 CVE-2023-30799
https://nvd.nist.gov/vuln/detail/CVE-2023-30799
Actual ???

ROS 6 CVE-2023-30799
https://nvd.nist.gov/vuln/detail/CVE-2023-30799
Actual ???

I see 6.49.8 is showing longterm, and 6.49.7 stable. Strange

6.49.8 has been promoted to the long-term channel. At the moment, for v6, the long-term and stable releases are both the same - 6.49.8. There is a little mixup with the download page which will be fixed as soon as possible.

The only difference between stable and long-term releases is the name under, for example, the "/system resources" menu.

ROS 6 CVE-2023-30799
https://nvd.nist.gov/vuln/detail/CVE-2023-30799
Actual ???

So the vulnerability is relevant in v6.49.8 ????

If its the case, it needs to be fixed. It seems that you need a user that do have right to log inn to the router to use this vulnerability.
But I do not feel any pity for user leaving Winbox or HTTP admin gui open to the pubic.

If its the case, it needs to be fixed. It seems that you need a user that do have right to log inn to the router to use this vulnerability.
But I do not feel any pity for user leaving Winbox or HTTP admin gui open to the pubic.

Sometimes you have to give limited access to contractors,
and I don't want them to be able to elevate permissions

As stated in the CVE - "MikroTik RouterOS stable before 6.49.7...". Yes, 6.49.8 is built on 6.49.7. Thus it includes the same fix.

On CRS2xx, do you suggest keeping v6 ? We use them as plain switch to aggregate fibers... no use to put v7 on them?

Remote SSH login using a private key is not working on this release.
I have automated backup scripts via SSH that are broken after this upgrade :(

So is this just a recompilation/rerelease of 6.49.8 (stable) with no code changes? The original release has a different timestamp - "What's new in 6.49.8 (2023-May-22 16:07)"

Upgraded many RB760iGS, cAP-ac, RB4011, and CHR and everything looks good.

@davidalain do you mean using ROS as SSH client to connect to other devices?

@davidalain do you mean using ROS as SSH client to connect to other devices?

I made a backup script using shell script in a Linux machine.
So Mikrotik devices act as SSH servers and a Linux machine as the SSH client.

CCR1072, CCR1009, RB4011, and hEX S.

I made a backup script using shell script in a Linux machine.
So Mikrotik devices act as SSH servers and a Linux machine as the SSH client.

CCR1072, CCR1009, RB4011, and hEX S.

My case is similar to yours (using a RSA priv/pub key pair) and works perfectly after upgrade, at least on RB4011 and hEX S (RB760iGS) devices.

What was the previous version installed on your devices?

So 6.49.8 is now the latest and only version supported with v6,

How is the upgrade supported from v6.49.x to the v7?
Can I upgrade to the latest 7 version or do I need to go with some steps?
Do you have some date when v6 is out of support?

Thanks for info.

So 6.49.8 is now the latest and only version supported with v6,

How is the upgrade supported from v6.49.x to the v7?
Can I upgrade to the latest 7 version or do I need to go with some steps?
Do you have some date when v6 is out of support?

Thanks for info.

I have a ccr2004 with many bgp feeds, gre and sit tunnels, that I would like to upgrade too, but I wonder the best way to do that.

It depends on your configuration and your model of router whether your upgrade to v7 will be easy or you need to take some preparing steps (or even not want to do it).

Do you NEED to upgrade to ROS7 ?
And for what devices ?

Some devices will not run ROS7 efficiently (e.g. everything with less then 64Mb RAM).
If there are no features in ROS7 which you are currently missing, there is no need to upgrade.

Other then that, depending on your config, an upgrade can be smooth sailing or might need some interventions.
See here:
https://help.mikrotik.com/docs/display/ ... ding+to+v7

Also you need to really study and test the upgrade before you do any upgrades in a production environment. E.G. in the help document it says:

BGP
All known configurations will upgrade from 6.x to 7.x successfully.

Well, that for sure is not correct, I have mentioned several times on the forum that not all configurations upgrade successfully, and you need to prepare.
E.g.:
- routing filters now have an implicit "reject" at the end, that used to be an implicit "accept". You may need to add an "accept" to your filters, depending on what they do and how they are structured
- in the peer configuration, update-source can no longer be the name of an interface, it HAS to be an address.
- in the networks configuration, it is no longer possible to have networks without the "synchronize" option
- route aggregation is no longer supported

So it is advisable to first rework your v6 configuration to adapt to the above, before you attempt an in-place upgrade.

Also you need to really study and test the upgrade before you do any upgrades in a production environment. E.G. in the help document it says:

BGP
All known configurations will upgrade from 6.x to 7.x successfully.

Well, that for sure is not correct, I have mentioned several times on the forum that not all configurations upgrade successfully, and you need to prepare.
E.g.:
- routing filters now have an implicit "reject" at the end, that used to be an implicit "accept". You may need to add an "accept" to your filters, depending on what they do and how they are structured
- in the peer configuration, update-source can no longer be the name of an interface, it HAS to be an address.
- in the networks configuration, it is no longer possible to have networks without the "synchronize" option
- route aggregation is no longer supported

So it is advisable to first rework your v6 configuration to adapt to the above, before you attempt an in-place upgrade.

Thank you so much for this helping advice!!!

As stated in the CVE - "MikroTik RouterOS stable before 6.49.7...". Yes, 6.49.8 is built on 6.49.7. Thus it includes the same fix.

I visited a lonely page that feels completely neglected by Mikrotik: https://blog.mikrotik.com/security/ also supplies RSS feed for Mikrotik.

I visited a lonely page that feels completely neglected by Mikrotik: https://blog.mikrotik.com/security/ also supplies RSS feed for Mikrotik.

+1 and it isn't clear if that CVE-2023-30799 was only addressed in 6.49.7 onwards, or also in 6.48.7 LTS which was released at a later date - there is nothing in the release notes.

... it isn't clear if that CVE-2023-30799 was only addressed in 6.49.7 onwards, or also in 6.48.7 LTS which was released at a later date - there is nothing in the release notes.

No, post #22 above probably sums up the status completely (not mentioning 6.48.7 does mean something). But since 6.49.8 is now LTS, it doesn't matter if the vulnerability is fixed in 6.48.7 or not.

Regarding upgrade to v7.
Yes, the preparation is needed in general, that is right.

But my point is the official position of Mikrotik.
There is difference if the migration is supported officially or not. For example v7.10 supports migration, but 7.11 not etc,
For me it seems that migration is supported in general with all versions and probably will be, but looking for some more official information.
The same with v6 lifespan.

For me there is no need no upgrade to v7, but good to know for future planning.

... it isn't clear if that CVE-2023-30799 was only addressed in 6.49.7 onwards, or also in 6.48.7 LTS which was released at a later date - there is nothing in the release notes.

No, post #22 above probably sums up the status completely (not mentioning 6.48.7 does mean something). But since 6.49.8 is now LTS, it doesn't matter if the vulnerability is fixed in 6.48.7 or not.

The problem is that the place where Mikrotik could provide clearity is not used. Now we have to go through several posting to have an answer.

It looks to me like that Mikrotik is somekind ashamed of having to admit that CVE are resolved. The blog is burried and can't be found on the Mikrotik site itself...atleast I could not find it there.

Maybe Normis is going to make a catchy YouTube video for each CVE concering Mikrotik, in the future.

Please adjust the download page.

There is difference if the migration is supported officially or not. For example v7.10 supports migration, but 7.11 not etc,

That just doesn't make sense. Even starting from version 7.0 migration was supported officially. Of course there were many problems, and depending on your usage scenario versions below 7.10 may be completely unusable, but with every higher version it generally becomes better.
(of course new bugs are also sometimes introduced)
I advise you to study the material cited above and the experiences posted by users on the forum before trying the upgrade, especially on critical or remotely located devices.

... it isn't clear if that CVE-2023-30799 was only addressed in 6.49.7 onwards, or also in 6.48.7 LTS which was released at a later date - there is nothing in the release notes.

No, post #22 above probably sums up the status completely (not mentioning 6.48.7 does mean something). But since 6.49.8 is now LTS, it doesn't matter if the vulnerability is fixed in 6.48.7 or not.

In my opinion it doesn't, all it states is that 6.49.8 includes the fix which was implemented in 6.49.7. The release notes for neither reference this CVE being fixed, so I don't see how the inclusion or absence in 6.48.7 LTS can be inferred.

Given that 6.48.7 LTS was released 2023-May-23 it should include any critical vulnerability fixes which were included in 6.49.7, released some seven months earlier, otherwise what's the point of having an LTS branch? And why wasn't there an LTS release at that time either?

Thanks!

Not tested on 6.49.8 but probably applies to this version as well:
⚠️Security Issue: Changing rights / disable / delete the users has no effect on already logged in users. [Tested on 6.48.7 and 7.10.2]
viewtopic.php?t=198410

That was a bust. Upgrading from previous long-term did not go well on a 750gr3.
Basically lost all entries in all but one address-lists, and even the one that had entries had been truncated badly after the upgrade (~29000 entries showing only). What is interesting is that the address lists names were showing in Winbox, even though there were zero entries in each (command line showed zero as well). Needless to say that device was borked for service and had to be replaced with another device that was on site (a cold-spare backup of the same device that unfortunately had 2.5 year old configuration). Total number of address-list entries in the pre-upgrade configuration was just shy of 70000, of which about 69000 in one address-list (both static and few dynamic entries) another address list had 846-900 static only entries in it and another 6 address lists had between 3 and 25 static-only entries.
Another lesson learned - always make and download a backup of a device before upgrade.. I didn;t expecting that this was a simple long-term to long-term upgrade with changelog identical to currently running release.

Another lesson learned - always make and download a backup of a device before upgrade.. I didn;t expecting that this was a simple long-term to long-term upgrade with changelog identical to currently running release.

Maybe you should read the first post in the release topic:
Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;

Probably the storage in your device was full and/or the database had been corrupted. The same problems may have occurred when you simply rebooted the device without upgrade!
I would say 70000 address list entries is too much to ask of this low-end device, but I have no hard numbers for that.
Your problems are 99% sure not related to the upgrade or the new version.

I would say 70000 address list entries is too much to ask of this low-end device,

My experience: I've had my hAP ac2 running 6.47.x and four lengthy address lists, two were IPv4 address lists (5.4k and 8.8k subnet addresses) and two were IPv6 address lists (1.9k and 2.7k subnet addresses). It was working fine with something like 0.5MB free storage (but I did have it installed with unbundled packages, this might have helped). Then I netinstalled the device to 7.9.1 and it worked just fine until I tried to install those address lists again. At this stage storage space was exhausted (with incomplete address lists installed) and I couldn't even clear the address lists. But otherwise device worked fine. I don't remember if there were any ill effects when rebooting device since I noticed the problem with lack of storage pretty soon.
So it was netinstall again, this time without those address lists (and with 0.8MB storage free).

Yes, I agree with @pe1chl that devices with less than 128MB storage (hEX has 16MB as well) should not be burdened with lengthy address lists ... where "lengthy" is anything larger than 1000 addresses.

Yes, but hAP ac2 is even worse than hEXr3 because the ARM architecture uses way more space than MMIPS or MIPSBE.
Still, one has to understand that so many config items take space in the config database, and some of that space is not reclaimed when deleting them, so when it in fact is a kind of dynamic list that is regularly changed (downloaded from an external server, for example) it is even worse.

Well, I don't agree fully with you pe1chl. Yes, the HEXr3 only has 16mg flash, which is extremely surprising. It is more expensive to buy 16mb flash chips than 128mb flash chips and has been for the last 4 years at least, but even with that:
a) after copying the lists from another device that had them, the full encrypted backup is 990kb. And a good part of that is PKI certificates.
b) the lists were not the last thing in the configuration, yet they are the only ones that got mangled. the configuration that is after the lists came over just fine
b) free space on the device with the lists back on is 23% - so 3.6mb - that is more than enough to backup the config
d) even if the space was not enough, MTK software should detect the inability to perform the upgrade successfully and abort it with appropriate log entries to ensure that the device remains operational.
It was unusual to have those lists that big, normally they get built by the router due to firewall rules hits, but once a month get pulled back, aggregated (and some other processing), and replaced with the aggregates, which reduce them to about 1200-1400 total entries. The update was done just a few days before this process.

New version v6.49.10 has been released:
viewtopic.php?t=198941