RouterOS version 6.45.8 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.45.8 (2020-Jan-23 07:19):

Changes since 6.45.7:

*) capsman - fixed background scan showing incorrect regulatory domain mismatch error (CAP upgrade required);
*) capsman - improved radar detection algorithm;
*) chr - improved stability when changing ARP modes on e1000 type adapters;
*) console - fixed "clear-history" restoring historic actions after power cycle;
*) console - removed "edit" and "set" actions from "System/History" menu;
*) console - updated copyright notice;
*) crs305 - disable optical SFP/SFP+ module Tx power after disabling SFP+ interface;
*) dhcpv4-server - improved stability when RADIUS interim update is sent;
*) dhcpv6-client - fixed timeout when doing rebind;
*) dhcpv6-client - properly update bind time when unused prefix received from the server;
*) dhcpv6-client - properly update IPv6 address on rebind;
*) dhcpv6-server - fixed logged error message when using "address-pool=static-only";
*) dhcpv6-server - ignore prefix-hint from client's DHCPDISCOVER if static prefix received from RADIUS;
*) health - fixed health reporting on OmniTIK 5 PoE ac;
*) ipsec - improved system stability when processing decrypted packet on unregistered interface;
*) l2tp - improved system stability when disconnecting many clients at once;
*) led - fixed default LED configuration for RBLHG-2nD and RBLHG-5HPnD;
*) lte - show SIM error when no card is present;
*) ppp - fixed connection establishment when receiving "0.0.0.0" DNS;
*) ppp - fixed minor typo in "ppp-client" monitor;
*) ppp - prioritize "remote-ipv6-prefix-pool" from PPP secret over PPP profile;
*) qsfp - do not report bogus monitoring readouts on modules without DDMI support;
*) qsfp - improved module monitoring readouts for DAC and break-out cables;
*) routerboard - added "mode-button" support for RBcAP2nD;
*) security - fixed vulnerability for routers with default password (limited to Wireless Wire), admin could login on startup with empty password before default configuration script was fully loaded;
*) ssh - fixed output printing when "command" parameter used;
*) timezone - updated time zone database to version 2019c;
*) traffic-generator - improved memory handling on CHR;
*) w60g - fixed "monitor" command on disabled interfaces;
*) winbox - automatically refresh "Packets" table when new packets are captured by "Tools/Packet Sniffer";
*) winbox - show "LCD" menu only on boards that have LCD screen;
*) wireless - added "ETSI" regulatory domain information;
*) wireless - added "indonesia4" regulatory domain information;
*) wireless - added U-NII-2 support forRBSXTsqG-5acD, RBLHGG-5acD-XL, RBLHGG-5acD, RBLDFG-5acD, RBDiscG-5acD;
*) wireless - allow using "canada2" regulatory domain on US lock devices;
*) wireless - fixed sensor MAC address reporting in TZSP header;
*) wireless - improved compatibility by adding default installation mode and antenna gain for devices with integrated antennas;
*) wireless - improved compatibility for Switzerland wireless country profile to improve compliance with ETSI regulations;
*) wireless - improved IPQ4019, QCA9984, QCA9888 wireless interface stability;

For a full changelog please visit https://mikrotik.com/download/changelogs

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.

>>Changes since 6.45.7
previous version was 6.44.6

Hopefully v6.45.8 hasn´t inherited wireless problems from v6.46.x...?

Just as a quick remind: on https://mikrotik.com/download/changelog ... lease-tree I can see text like this "Changes since 6.45.7" but see no info on 6.45.7 at all, pre version is 6.44.6.

So the question is, ain't it is a just from 6.44.6 -> 6.45.8? Or this is a mistake so in fact this should be 6.44 branch, like this: 6.44.6 -> 6.44.7 -> 6.44.8?

This is correct. Listed here are only changes between 6.45.7 and 6.45.8. If you want to know all changes between 6.44.6 and 6.45.8, you have to go through all versions that were released in between.

there are no other versions between them

6.45 to 6.45.7 versions were released in stable channel only, not in long-term.

there are no other versions between them

long-term isn't a different firmware branch
it's a regular firmware (6.45.7 in our case) plus bugfixes and improvements only, without adding new functionality

6.45 to 6.45.7 versions were released in stable channel only, not in long-term.

This issue has been discussed previously and seems we have to discuss it again: if an user is subscribed to "long term", then he needs to be alerted about all changes between sequential "long term" releases regardless the release cycle. If "long term" release 6.44.6 is succeeded by "long term" release 6.45.8, then change log presented to such user should contain a merged list of changes of all changes between these two versions.
Ideally change log presented to the user would be dynamically merged list of changes between currently installed ROS and the version about to be installed. I can imagine this can pose some more work with change log organization and if MT doesn't have some change log creation system in place (and change logs need to be prepared manually), then I guess we can live without this kind of change log. However, if "long term" release includes jump in many versions, then somebody should manually merge relevant release change logs.

After all, MT wants users to believe that it's fine to follow the release decisions by MT without micro-managing upgrades ... hence the process should flow accordingly (and change log is part of the process).

BTW, upgrades involving large version jumps (e.g. from 6.40.x to current "long term" version) should be done with regard to upgrade scripts. We've seen many times that upgrade scripts don't handle large differences in configuration. In this case, upgrade process should involve upgrade to interim versions which handle upgrades of config smoother. One example of such upgrade path is Firefox ... if one is running too old version, upgrade doesn't jump directly to current version, it upgrades to one (or few) interim versions ...

there are no other versions between them

long-term isn't a different firmware branch

No, it's not. "long term" is a release channel.

MT currently runs 4 channels:

1. long term, which recently experienced version jump from 6.44.6 to 6.45.7
2. stable, which currently stands at 6.46.2 and normally steadily runs through all "non beta" releases
3. testing, which actually is "beta for v6" as it is now. After certain beta version gets bugs fixed (or at least devs think so), the last one becomes "stable" release
4. development, which doesn't exist all the time. Currently its "beta for v7" ...

Conservative user, who doesn't need all the new features but prefers (or requires) bug-free stability, can opt for "long term" release channel. And upon proposed/forced ROS upgrade that user would expect to see change log between "his" consecutive versions.

there are no other versions between them

long-term isn't a different firmware branch

No, it's not. "long term" is a release channel.

MT currently runs 4 channels:

1. long term, which recently experienced version jump from 6.44.6 to 6.45.7
2. stable, which currently stands at 6.46.2 and normally steadily runs through all "non beta" releases
3. testing, which actually is "beta for v6" as it is now. After certain beta version gets bugs fixed (or at least devs think so), the last one becomes "stable" release
4. development, which doesn't exist all the time. Currently its "beta for v7" ...

Conservative user, who doesn't need all the new features but prefers (or requires) bug-free stability, can opt for "long term" release channel. And upon proposed/forced ROS upgrade that user would expect to see change log between "his" consecutive versions.

Yes I know that. I used wrong term, while understand the concept.

What is strange, I hardly understand how each release "marked", say, to be long-term or not. I can't believe it it easy to determine that this current release "seems to be super-stable so put is under long-term". If so it looks too dangerous to believe that long-term is really-long-term so one can put it onto reouter that should won't long time without upgrades and will not show signs of bugs/problems.

So yes, good explanation in each case of big version bump would be nice and (really) a must.

I can imagine a sysadmin that try to choose which version to put on router/switch that'll be work remotely and without close human presence. This way the ROS may not be very current, but very stable (trust-worth), and this is what long-term should be about, right?

Have you guys checked the changelog on your routers? The 6.45.8 changelog contains of all versions between the last long-term version. We can not predict from which version a user is upgrading in a forum topic or on a website. Please stop going off topic. This is not the place to discuss how changelogs should be published! Any further off topic posts will be removed and users will be warned.

Please stop going off topic.

I express my question on version number bump - and this is the topic for this version, isn't it? It you guys can not describe what you're doing in the first message, then be prepared to see these questions. Please consider these ideas, we are your customers and someone who keep buy your devices and licenses mainly due to ROS unique place on market, and yes we need a way to determine if current (or upcoming) version to be considered as quite stable or you just name it "release" instead "beta" (you can recall versions that infamous for being non-stable even that it was called 'release'). Read changelog on device is good (but naive) idea but there are people who prefer to do cli-based upgrade, mind it?

I just installed 6.45.8 on one router to check it and keep eye on it, the upgrade is ok so far it works nice, too.

...
it's a regular firmware (6.45.7 in our case) plus bugfixes and improvements only, without adding new functionality

I suspect the long term version does include new functionality, but only once it has been vetted via the stable release

Long term: Released rarely, and includes only the most important fixes, upgrades within one number branch not add new features.
https://wiki.mikrotik.com/wiki/Manual:U ... _numbering

...
it's a regular firmware (6.45.7 in our case) plus bugfixes and improvements only, without adding new functionality

I suspect the long term version does include new functionality, but only once it has been vetted via the stable release

Well, if you upgrade from 6.44.6 (previous long-term) to 6.45.8 OF COURSE it includes new functionality. It does not if you upgrade from 6.45.7 to 6.45.8.

...
it's a regular firmware (6.45.7 in our case) plus bugfixes and improvements only, without adding new functionality

I suspect the long term version does include new functionality, but only once it has been vetted via the stable release

Well, if you upgrade from 6.44.6 (previous long-term) to 6.45.8 OF COURSE it includes new functionality. It does not if you upgrade from 6.45.7 to 6.45.8.

Indeed. The question was why is that huge jump when we talk about long-term. Logics behind is an Terra Unknown for me, so some explanation would be just perfect add-on for the announcement, dont't you think so?

iWell, if you upgrade from 6.44.6 (previous long-term) to 6.45.8 OF COURSE it includes new functionality. It does not if you upgrade from 6.45.7 to 6.45.8.

Indeed. The question was why is that huge jump when we talk about long-term. Logics behind is an Terra Unknown for me, so some explanation would be just perfect add-on for the announcement, dont't you think so?

And published today, very timely...

17 answers and none about the release. It probably means that the release is stable indeed
All this discussion should be put in another topic guys if you are unhappy about the release channels and how are those named.
If you check from winbox the change log that appears at /system package you will see that it has all changes since 6.45. Is there a better way to alert a user about the change log?

ltAP mini & RB4011iGS+5HacQ2HnD-IN on 6.45.8 ... so far .. so good

If you check from winbox the change log that appears at /system package you will see that it has all changes since 6.45. Is there a better way to alert a user about the change log?

No indeed, but do you mind to consider cli-only setups? Mikrotik site is the default place for changelogs as for me and this time this mess prevented me and maybe some other persons from understanding the whole picture of changes, this was the reason to ask about.

So to say, winbox under linux can be run in wine only, while ssh is always there. And winbox is not good tool to read huge changelogs as well.

I'm having a problem with the hotspot after versions 6.45 the hotspot simply does not redirect to the login screen until version 6.44.6 worked correctly

Very, very bad finding about performance of hAP ac2 for all ROS version after 6.43.16. Triple checked - for clear routing in all new versions the load is distributed over only 2 cores, which results in half of the performance in comparison with 6.43.16!!!

Test1 - ROS 6.43.16 clear routing of 700Mbps between two interfaces - RESULT 0% loss

[admin@hAPac^2] > system resource cpu print interval=1
# CPU LOAD IRQ DISK
0 cpu0 64% 57% 0%
1 cpu1 73% 73% 0%
2 cpu2 90% 84% 0%
3 cpu3 93% 86% 0%

[admin@hAPac^2] > interface monitor-traffic ether2,ether3
name: ether2 ether3
rx-packets-per-second: 142 972 142 963
rx-bits-per-second: 706.8Mbps 707.5Mbps
fp-rx-packets-per-second: 143 815 143 815
fp-rx-bits-per-second: 706.4Mbps 706.4Mbps
rx-drops-per-second: 0 0
rx-errors-per-second: 0 0
tx-packets-per-second: 143 062 143 121
tx-bits-per-second: 707.2Mbps 707.5Mbps
fp-tx-packets-per-second: 143 816 143 815
fp-tx-bits-per-second: 706.4Mbps 706.4Mbps
tx-drops-per-second: 0 0
tx-queue-drops-per-second: 0 0
tx-errors-per-second: 0 0

Test2 - ROS 6.45.8 clear routing of 700Mbps between two interfaces - RESULT 40% loss

[admin@hAPac^2] > system resource cpu print interval=1
# CPU LOAD IRQ DISK
0 cpu0 0% 0% 0%
1 cpu1 100% 98% 0%
2 cpu2 0% 0% 0%
3 cpu3 100% 100% 0%

[admin@hAPac^2] > interface monitor-traffic ether2,ether3
name: ether2 ether3
rx-packets-per-second: 141 657 141 657
rx-bits-per-second: 700.3Mbps 700.3Mbps
fp-rx-packets-per-second: 83 981 85 843
fp-rx-bits-per-second: 412.5Mbps 421.6Mbps
rx-drops-per-second: 0 0
rx-errors-per-second: 0 0
tx-packets-per-second: 86 197 84 293
tx-bits-per-second: 426.1Mbps 416.7Mbps
fp-tx-packets-per-second: 85 843 83 981
fp-tx-bits-per-second: 421.6Mbps 412.5Mbps
tx-drops-per-second: 0 0
tx-queue-drops-per-second: 0 0
tx-errors-per-second: 0 0

There are big changes between the two versions. Open a new topic with your config and so on, or contact MikroTik support.

If you check from winbox the change log that appears at /system package you will see that it has all changes since 6.45. Is there a better way to alert a user about the change log?

No indeed, but do you mind to consider cli-only setups? Mikrotik site is the default place for changelogs as for me and this time this mess prevented me and maybe some other persons from understanding the whole picture of changes, this was the reason to ask about.

So to say, winbox under linux can be run in wine only, while ssh is always there. And winbox is not good tool to read huge changelogs as well.

I am sorry but what mess are we discussing. If you go to mikrotik site you will see the change log. If winbox does not suit you consider webfig.
It looks like all you want is the whole change log at the opening post, that might be a huge space consuming and not suitable for people who navigate via smartphone or other means. There is even a link on the opening post to look at the whole change log.

Here's the problem with reading through change logs: long-term channel experienced version change from 6.44.6 to 6.45.8. Fine, this includes change log between 6.45.7 and 6.45.8. And one can skim through consecutive change logs until one comes to change log of 6.45.1, which lists "MAJOR CHANGES IN v6.45.1" and "Changes in this release" but doesn't state which version it's related to. 6.45(.0) was "factory only" without change log ... and one can only guess which version preceded 6.45.1 ... was it 6.44.6 or 6.44.5 or ...? According to change logs in stable channel (mind that such admin is interested in long-term not in stable channel) 6.45. was preceded by 6.44.3 (with two factory-only releases in between). And then admin would have to "unroll" changes in 6.44 branch (so 6.44.6 less 6.44.5 less 6.44.4) and then add changes in branch 6.45 until 6.45.8.
I'd say that given that there are tens of thousands of MT admins (and "admins") and at least hundreds of those who care, it would be highly sensible for MT to provide "cleansed" change log between versions which chronologically follow each other in long-term channel.

I promise not to post another word on this topic for at least a month or two. Over&out.

I think some confusion and unrest may relate to the wording chosen in the release notes. Previously (up to and including 6.44.6) the changelog started with "MAJOR CHANGES IN v[new release no.]" and did not state any since version number. The current heading for the v6.45.8, however, starts with a line "Changes since 6.45.7".

I think it is correct to point out that the question now arises whether this obvious difference reflects an intentional change in practice, or if it is just an unintentional small mistake, and in fact a "MAJOR CHANGES IN..." section was intended to be published.

If you consider the above to be off topic, feel free to ignore.

On topic: No discernible problems experienced upgrading a ccr1009, a crs210, and six rb912uag-5hpnd from 6.44.5 to 6.45.8 - thanks for the good work!

CCR1009-7G-1C-1S+ 6.44.6 -> 6.45.8

ip ipsec policy peers where is state unknown.. IPSEC tunnels -- some were working some not..
Manualy specified correct peers sand flushinng SAs solved the problem without reboot.

Everything else seems to be working after upgrade..
.
Kudos for :
/ip ipsec active-peers print

So we can see connected tunnels and RoadWarriors (IKEv2 with NPS)!!!
Is there any way to have a log of VPN users connections times and duration (history)

I have mANTBox19S, with version 6.44.6 there were no problems, after updating to 6.45.8, the device rebooted twice, with approximately the same interval of 24 hours, the settings did not changes, there are no logs yet, I am waiting for the third reboot today. And yet, in system/health appeared fan management.

adding, waited for the 3rd reboot, reboot on the watchdog timer, I do not use it and the default settings.

no this problems with :
ccr1016-12g, hAP, hAP lite, rb951ui-2hnd,sextant-g,mATNBox2-12s, hEX-PoE, LHG-2-XL, SXTsq5-ac, SXT2.

Same problem on hAp AC². Random reboots in 6.45.8 [long term] and ≥ 6.46 [stable].
Prior to these versions there was no problems.

I can confirm unexpected reboot on HAP AC^2 15 hours ago (backed by UPS, no power issues).
No information in log.
Haven't seen such reboots before on 6.44.6 and 6.45.7.
Other devices (not HAP AC^2) seems work without reboots.

hi,
for me no reboot problems with hap ac2 (uptime 26h), but I have another problem. I have a Netgear modem configured in bridge mode to my RB3011 and the dhcp client on the interface so the public address is released directly to the mikrotik. I've also configured a private lan between the mikrotik and the Netgear to manage the modem but after the upgrade to the 6.45.8 the modem is unreachable (ping, web interface, others...). If I disable the dhcp client the modem come back reachable. No problem with the prior version 6.44.6.

I've upgraded successfully the following devices without issues at this moment:

- hAP ac2
- hAP AC Lite
- hAP AC
- RB3011UiAS-RM
- RB2011UiAS-2HnD
- RB2011UiAS-RM
- hEX

Hello.
Apart from some IPSEC issues, the peer need now to be specified, lost only 2 x Hap AC Lite. No lights, nothing. Router died.
Need to wait to get to the office to make in-depth verifications.

Another issue:
on a CCR in my Fiber POP, it just create dynamic queues with ipv6 class when a customer's router get a ipv6 dhcpv6 lease.
On other 8 POPS, same configuration, it doesnt happen.

hap ac2 hovered twice a day
rb4011 received a critical error and was rebooted

I have 3 hap ac2 on 6.45.8. Don't any reboot. Who reboots - do you have an ntp package and does your ntp server work? I have rebooting from version 6.43.15 on all hap ac2. After removing this package, the reboots stopped on all hap ac2.

I cannot login via api after upgrade

"I cannot login via api after upgrade"

Or:

"I cannot login via api after upgrading from [version] to this v6.45.8. I am using [api implementation] in [language] documented here [url]. The code I am using is:

[short login code fragment]

I am getting the following result: [result from Mikrotik] or the following error message: [error message].

I have read the change logs and am aware of the v6.43 api login changes as documented here: https://wiki.mikrotik.com/wiki/Manual:API#Initial_login"

I upgraded from v6.45.6 using PHP API below:
https://github.com/BenMenking/routeros- ... .class.php

It was working fine before update.

I upgraded from v6.44.6 using PHP API below:
https://github.com/BenMenking/routeros- ... .class.php

It was working fine before update.

Problem with 3rd party script not mikrotik.

Sent from my VTR-L29 using Tapatalk

I upgraded from v6.44.6 using PHP API below:
It was working fine before update.

Problem with 3rd party script not mikrotik.

Sorry, It was v6.45.6, not v6.44.6.
The script was working fine with v6.45.6, then why there is problem with that script but not Mikrotik?

I upgraded from v6.44.6 using PHP API below:
It was working fine before update.

Problem with 3rd party script not mikrotik.

Sorry, It was v6.45.6, not v6.44.6.
The script was working fine with v6.45.6, then why there is problem with that script but not Mikrotik?

Was replying to version 44.6 as the new login came into affect after 45.1

Sent from my VTR-L29 using Tapatalk

Who reboots - do you have an ntp package and does your ntp server work?

Removing this package solved the problem. Thanks.

Developers, pay attention to problems with ntp package on arm processors.

Upgraded to 6.45.8 (from 6.44.5) but no SNMP readout by DUDE anymore. DUDE has been running for more than a year with no problems. After the upgrade only the upgraded SXT LTE cannot be read out. SNMPWALK gives timeout as well.

UPDATE not clear what is the cause. Clicked away from this entry in the' browser, but it was posted anyway (sorry). Upgraded to 4.46.3 no luck. Downgraded to 6.44.5, still no luck. Finally rebooting intermediate balancing router and it was back. Will upgrade later.

Possible bug: Unable to import 4096 RSA public key at 6.45.8: At 6.46.2-6.46.3 and other previous versions, exactly the same file imports successfully!

RE: RBwAPG-5HacT2HnD fails to work with 6.45.8.

After several Netinstall(ing) of 6.45.8 on my RBwAPG-5HacT2HnD, the device fails to boot up each time, despite Netinstall app indicates a successful firmware transfer each time. (I have not been able to upgrade firmware via Files for some unknown reason. It simply ignores 6.45.8 and drops all packges off after a system reboot! Hence Netinstall).

I used same process and backed down to 6.44.6, the device boots up properly and works again. Note: I am not sure if it's just my box or its the same situation with every other RBwAPG-5HacT2HnD.

Be warned. Sorry, but I cannot supply any other info.

Cheers.

anuser - To what kind of a problem do you refer to
ViniciusMariano - Seems like the issue which is not resolved in v6.46.3 and v6.47beta. Fix will also be included in the next long-term release
kos - We are currently looking into this
huntah, sport80, Maggiore81, bpwl - If you do experience such a problem once more, then please generate supout file while the issue is present on the router and send it to support@mikrotik.com
jhonykat - Most likely you do have to update login method - https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
XaTTa6bl4 - Try to do the same again and right after that generate supout file. Send this file to support@mikrotik.com
MTeeker - Try to upgrade and right after that check log. If you cannot determine why the package was not installed, then generate supout file and send it to us.
attl, DimaFIX, thedix, DenisPDA, Traveller, DimaFIX - You will not ever be able to determine the cause of the reboot in the forum. If your router is rebooting by itself, then contact support@mikrotik.com right away and provide supout file. Forum posts regarding a crash due to NTP service is a random guess without any reason. Only MikroTik staff can determine the precise cause of the problem and if it is caused by the software, then we want to fix this problem as soon as possible. If you even manage to workaround a problem based on other user experience, then the issue is still there and others suffer from it. All bug reports are very welcome

Dear Strods,

As suggested, I have now submitted the Supout.rif file together with relevant details regarding version 6.45.8 not working on RBwAPG-5HacT2HnD.

Cheers,
MTeeker

attl, DimaFIX, thedix, DenisPDA, Traveller, DimaFIX - You will not ever be able to determine the cause of the reboot in the forum. If your router is rebooting by itself, then contact support@mikrotik.com right away and provide supout file.

Ok, I sent two suppout.rif files according two reboot in 5 minutes (!). Let's see what the answer will be .

Hallo everybody,
couple of mipsbe devices upgraded in a long-term line (i.e. from 6.44.6) with no issues encountered so far (IPv6, GRE tunnels over IPsec, OSPF v2 and v3, BGP, etc.). Thanks to Mikrotik for their work.

attl, DimaFIX, thedix, DenisPDA, Traveller, DimaFIX - You will not ever be able to determine the cause of the reboot in the forum.

I just turned off the watchdog and reboots stopped

Removing this package solved the problem. Thanks.

Ok, I sent two suppout.rif files according two reboot in 5 minutes (!). Let's see what the answer will be .

DimaFIX, Traveller There is a separate post about hAP ac2 random reboots (that seem to be solved by removal of NTP package): viewtopic.php?f=2&t=153988
Could you please mention there whether you are using IPSec (or any other non-default features) on the problematic routers?
Traveller Thank you very much for creation of the support ticket! Can you please mention the ticket number (I think having as much info as possible in the forum might be helpful)?

attl, DimaFIX, thedix, DenisPDA, Traveller, DimaFIX - You will not ever be able to determine the cause of the reboot in the forum. If your router is rebooting by itself, then contact support@mikrotik.com right away and provide supout file. Forum posts regarding a crash due to NTP service is a random guess without any reason. Only MikroTik staff can determine the precise cause of the problem and if it is caused by the software, then we want to fix this problem as soon as possible. If you even manage to workaround a problem based on other user experience, then the issue is still there and others suffer from it. All bug reports are very welcome

Traveller has contacted MikroTik support and sent the supout files. I really hope MikroTik will fix this issue soon! The forum topic referred in beginning of this post might also provide some helpful clues.
Here is also a related feature suggestion that (if not already implemented) might help MikroTik staff to "determine the precise cause of the problem" and similar problems.

...Unable to import 4096 RSA public key at 6.45.8...

Sorry, It was my bad, I found that two slashes (\\) was into key file. Apparently newer versions of ROS just ignore it.

anuser - To what kind of a problem do you refer to
ViniciusMariano - Seems like the issue which is not resolved in v6.46.3 and v6.47beta. Fix will also be included in the next long-term release
kos - We are currently looking into this
huntah, sport80, Maggiore81, bpwl - If you do experience such a problem once more, then please generate supout file while the issue is present on the router and send it to support@mikrotik.com

Thanks strods, i've send the supout file

Hi,

We updated most of our devices to new 6.45.8. After updating, we experienced very bad performance with ARM antennas (RBLHGG-5acD-XL). Antennas were all the time registering to the AP, dropping the sessions after few seconds and reconnecting immediately but customers were complaining they were unable to use the connection. After receiving the complains, we decided to rollback to last long-term release we had installed (which is 6.44.6) and everything went back to normal immediately (antennas uptime last for days instead of seconds).

Also regarding the issue: reading changelog to release 6.45.8, at the bottom part in the "wireless" section i see there is no mention to the point "wireless - improved 802.11ac stability for all ARM devices with wireless" which was solved in stable release 6.45.2. Do you know if there is any identified issue to ARM devices deliverately not being included in last long-term release?

Thanks,

After 20d online the 5GHz Wlan stops working again on my RB4011iGS+5HacQ2HnD-IN. The devices can not connect ... in winbox the interface is not running anymore. Only a reboot brings the interface back.
So there is no improvement with 6.45.8 with arm device RB4011iGS+5HacQ2HnD-IN.

Richard

I just found a serious problem on both HAP AC² and 750R3.
After I updated the device from V6.44.6 to V6.45.8, I created backup from the WebFig by "Files -> Backup" without encryption , after that, I made some changes on the configuration.
When I restore the routers with the backup file generated above and after the automatic reboot, I found that the changes made after the backup were still exist!
I did the same with the command line to backup (/system backup save) and restore (/system backup load) , the same problem exist.

However, I did the same thing on WAP AC, I noticed that after I pressed the "Backup" button on the WebFig, the screen was able to return back to the File list page. Furthermore, I could restore the WAP AC to previous state successfully.

I suspect the backup file generated in the routers are corrupted and not usable. Since this problem is severe in terms of service recovery. I urged the support to take a look into it seriously. Thanks.

After 20d online the 5GHz Wlan stops working again on my RB4011iGS+5HacQ2HnD-IN. The devices can not connect ... in winbox the interface is not running anymore. Only a reboot brings the interface back.
So there is no improvement with 6.45.8 with arm device RB4011iGS+5HacQ2HnD-IN.

Richard

I have the same issue.
Even with v6.46.4 [Stable] version of RouterOS.

Me too. Capsman seems to make it even worse.
Hap AC (without AC2, so not arm, stays stable)

I just found a serious problem on both HAP AC² and 750R3.
After I updated the device from V6.44.6 to V6.45.8, I created backup from the WebFig by "Files -> Backup" without encryption , after that, I made some changes on the configuration.
When I restore the routers with the backup file generated above and after the automatic reboot, I found that the changes made after the backup were still exist!
I did the same with the command line to backup (/system backup save) and restore (/system backup load) , the same problem exist.

However, I did the same thing on WAP AC, I noticed that after I pressed the "Backup" button on the WebFig, the screen was able to return back to the File list page. Furthermore, I could restore the WAP AC to previous state successfully.

I suspect the backup file generated in the routers are corrupted and not usable. Since this problem is severe in terms of service recovery. I urged the support to take a look into it seriously. Thanks.

Further investigating this case, I downgraded the routers back to V6.44.6 and re-did the experiment, the restoration was successful and all changes done after the backup were reverted.
I noticed the size of the backup in two version differing dramatically. In specific, the backup file size under V6.44.6 is about 1.1MB, but the size of backup file under V6.45.8 is just 640KB. Such difference maybe a proof of incomplete backup file generated in newer version which results in failure of restoration.

We are experiencing some OSPF/IP bug, for some reason OSPF change from full to init and i cant ping the other device, but i can reach it from another route, um a ccr1016 one ether/vlan stooped to make neighbor with a rb 2011 last sunday, today a rb2011 stooped to make neighbor with ccr again, last Sunday i needed to reboot ccr(oh shit), today i needed to reboot 2011 that could not make neighbor with ccr, but after reboot it all goes ok, before my core were with 43.2 working for a long long time without problem, with 45.8 after 12 days, 2 problems.

don't recommend use this version with ospf...

In specific, the backup file size under V6.44.6 is about 1.1MB, but the size of backup file under V6.45.8 is just 640KB. Such difference maybe a proof of incomplete backup file generated in newer version which results in failure of restoration.

Make sure you report this via email to support@mikrotik.com, as there is no guarantee that a problem reported only in the forum will get noticed in a timely fashion.

I upgraded some routers from 6.44.x to 6.45.8 and i've been experiencing VPLS issues in our network

More information here viewtopic.php?f=14&t=158525 but the basics are that VPLS tunnels are randomly stopping, won't go into running state. But everything I check manually (routing table, MPLS forwarding table) looks correct, no obvious issues. Only 'fix' is to reboot routers, even that doesn't always work. I'll be downgrading all routers to 6.44.6 tonight

We are experiencing some OSPF/IP bug, for some reason OSPF change from full to init and i cant ping the other device, but i can reach it from another route, um a ccr1016 one ether/vlan stooped to make neighbor with a rb 2011 last sunday, today a rb2011 stooped to make neighbor with ccr again, last Sunday i needed to reboot ccr(oh shit), today i needed to reboot 2011 that could not make neighbor with ccr, but after reboot it all goes ok, before my core were with 43.2 working for a long long time without problem, with 45.8 after 12 days, 2 problems.

don't recommend use this version with ospf...

True. We have ospf troubles too. Some ospf peers does not go up after downtime automatically. Even after interface up\down. OSPF goes up only after full instance manual shutdown/up... Too bad.

We have got a problem, after /system/routerboard upgrade firmware a RB4011wifi version has died suddenly. Only serial netinstall helped to relive it.
Routeros version v6.45.8 long-term
Is an isolate case or a bug?

I'm having a problem with the hotspot after versions 6.45 the hotspot simply does not redirect to the login screen until version 6.44.6 worked correctly

I can confirm this. I did a packet capture on the hotspot and worked out that in 6.44.6, the client device often ignores the "Hotspot login required" response to the first HTTP GET, and the client sends another HTTP GET and this time accepts the "Hotspot login required" response from the hotspot and correctly redirects to the login page.

On 6.45.8, the client again sends multiple HTTP GET requests, but the hotspot only replies to the first one, and never to subsequent requests. Hence the client never gets a redirect to the login page.

(My client in this test was a Samsung Galaxy S9 phone, Android 10.)

Hello.
Apart from some IPSEC issues, the peer need now to be specified, lost only 2 x Hap AC Lite. No lights, nothing. Router died.
Need to wait to get to the office to make in-depth verifications.

Another issue:
on a CCR in my Fiber POP, it just create dynamic queues with ipv6 class when a customer's router get a ipv6 dhcpv6 lease.
On other 8 POPS, same configuration, it doesnt happen.

Seriously guys, I am the only one to have the automatically created ipv6 queues?
That they even doesnt match traffic

Good night, has anyone been through this and could give me a light?
I have a CRS switch that I upgraded from version 6.43 to version 6.45.8.
On a port I have a SWO (260gs) connected.
I keep losing management.
Strange that if I enter the CRS switch and go to IP NEIGHBOR, the IP appears and also the mac addres, but not ping
However, in the SWO switch (WITHOUT MANAGEMENT) the clients on the same port, navigate ok, . is it bug?

I think 6.45.8 is a mess and feel that MikroTik should withdraw it. There's multiple issues with it and some of them are pretty damn serious

I think 6.45.8 is a mess and feel that MikroTik should withdraw it. There's multiple issues with it and some of them are pretty damn serious

Good Morning

Recommended to make down grade, which version?

CRS AND SWO

Is / has anyone else experience intermittent PPPoE drops with this version?

I have a customer which is a fairly large ISP which and experiencing this. Besides for 1 router at a high site where the uplink ethernet interface goes up/down intermittently, the network is stable. I have pointed out the interface "flapping" to them and they will address this in the morning, but besides this, I cant find anything causing the problem, nothing in the logs indicating reason, etc. hence the question if this might be the possible reason.

Call has been logged with Mikrotik Support, SUP-12274 and supplied the config export as well as 2 x supout files created immediately after the PPPoE crashed this eve.

I think 6.45.8 is a mess and feel that MikroTik should withdraw it. There's multiple issues with it and some of them are pretty damn serious

Good Morning

Recommended to make down grade, which version?

CRS AND SWO

I'm done with 6.45.8 (LT) and the current 6.46.4 (stable), even with 6.47beta 49. They all have very similar problems. (and 6.47 even lost the antenna gain setting in the GUI) .
Very unstable wifi performance, interface rate flapping, and connection dropouts. unsuccesfull associations .... etc etc. (wAP ac, hAP ac2, SXTsq, Omnitik 5 ac)
Downgraded them all to what I have in a larger installation: the old 6.45.6 stable with really stable wifi for months now, steady 400 Mbps interface rate on 40 MHz/2S/SGI on more than 10 devices
After downgrading I have now the same stable wifi network here.
Test environment with 7.0beta5 works well and stable with this 6.45.6 version


What went wrong in 6.45.7 (stable) or 6.45.8 (LT) ? .... there are many changes ! ... (LT should have only bug fixes compared to the corresponding stable release, not a whole list of changes)

True. We have ospf troubles too. Some ospf peers does not go up after downtime automatically. Even after interface up\down. OSPF goes up only after full instance manual shutdown/up... Too bad.

UP! I am also facing very random problems with OSPF, with this version and with 6.44.6. I opened a ticket and let's see what happens. What was the last version that did not have these problems?

We are experiencing some OSPF/IP bug, for some reason OSPF change from full to init and i cant ping the other device, but i can reach it from another route, um a ccr1016 one ether/vlan stooped to make neighbor with a rb 2011 last sunday, today a rb2011 stooped to make neighbor with ccr again, last Sunday i needed to reboot ccr(oh shit), today i needed to reboot 2011 that could not make neighbor with ccr, but after reboot it all goes ok, before my core were with 43.2 working for a long long time without problem, with 45.8 after 12 days, 2 problems.

don't recommend use this version with ospf...

True. We have ospf troubles too. Some ospf peers does not go up after downtime automatically. Even after interface up\down. OSPF goes up only after full instance manual shutdown/up... Too bad.

UP! I am also facing very random problems with OSPF, with this version and with 6.44.6. I opened a ticket and let's see what happens. What was the last version that did not have these problems?

Please tell us about ticket solving, if will be any news. We facing OSPF problems too...

We are experiencing some OSPF/IP bug, for some reason OSPF change from full to init and i cant ping the other device, but i can reach it from another route, um a ccr1016 one ether/vlan stooped to make neighbor with a rb 2011 last sunday, today a rb2011 stooped to make neighbor with ccr again, last Sunday i needed to reboot ccr(oh shit), today i needed to reboot 2011 that could not make neighbor with ccr, but after reboot it all goes ok, before my core were with 43.2 working for a long long time without problem, with 45.8 after 12 days, 2 problems.

don't recommend use this version with ospf...

True. We have ospf troubles too. Some ospf peers does not go up after downtime automatically. Even after interface up\down. OSPF goes up only after full instance manual shutdown/up... Too bad.

UP! I am also facing very random problems with OSPF, with this version and with 6.44.6. I opened a ticket and let's see what happens. What was the last version that did not have these problems?

Please tell us about ticket solving, if will be any news. We facing OSPF problems too...

To be more specific: problem with ospf occurs after large links flapping is case of carrier isp troubles, etc. OSPF cannot goes up on random routers after that. Only manual instance up\down solves this issue.

To be more specific: problem with ospf occurs after large links flapping is case of carrier isp troubles, etc. OSPF cannot goes up on random routers after that. Only manual instance up\down solves this issue.

Yes yes, I am also facing this problem, in addition to random state changes, at different times in OSPFv2 and v3, in different parts of the network, without physical failure, no configuration problems. We have a CCR1016-8S-1S + that every day has a drop in the interfaces very fast, in every drop ospfv2 returns and v3 does not, being necessary to turn off / on the ospfv3 instance to return.

@allencesar and @bda

Is it a problem for you to press "Post replay" instead of quoting quotes of quotes ? Do you think it makes reading your discussion more readable?

Here also problems with OSPF 24 hours after upgrade. Problems only in 1 CCR of a 10 units farm, but a big headache to identify were the problem was. Solved with reboot. Next night i will downgrade to 6.44.6.

Hi

I would like to report a bug with this version:
If there is no port active on switch1 I get these errors straight after a reboot. Runnig the print command twice or enabling a port on switch1 seems to trigger more massive error counts.
This is related with my other post viewtopic.php?f=2&t=159543

Cheers,
Harry

rotten information https://wiki.mikrotik.com/wiki/Manual:Peripherals

when will you update the information ? or users will buy and run wit

rotten information https://wiki.mikrotik.com/wiki/Manual:Peripherals

If your post is about LTE modems ... then I guess the information on the page you linked is as acurate as it gets ... MT did not upgrade kernel used in ROS for a while and (sadly) new peripherials are not supported by a 9 year old kernel. I'm pretty sure that support for modems will dramatically improve in ROS v7.

rotten information https://wiki.mikrotik.com/wiki/Manual:Peripherals

If your post is about LTE modems ... then I guess the information on the page you linked is as acurate as it gets ... MT did not upgrade kernel used in ROS for a while and (sadly) new peripherials are not supported by a 9 year old kernel. I'm pretty sure that support for modems will dramatically improve in ROS v7.

as i have read in forum, the RouterOS v7 has v4.14

Here also problems with OSPF 24 hours after upgrade. Problems only in 1 CCR of a 10 units farm, but a big headache to identify were the problem was. Solved with reboot. Next night i will downgrade to 6.44.6.

Mespinos, do you have any news on this problem?

Hi,

We have severals (12) CCR that fails on upgrade. All fails after reboot and it stucks on booting. Making a manual reboot puts device into boot loop.

we can't make a supout.rif because device doesn't boot. Only thing that we can do to recover is a netinstall.

There are several scenarios but simpliest is a new ccr "put out the box".

Previous version was 6.42 and 6.43 an we use stable channel only.

I don't know if there are some intermediate version that must be installed previous to 6.45, but reading all changelogs i think no.

Anyone can help?

Regards!

dmartl wrote:
I don't know if there are some intermediate version that must be installed previous to 6.45, but reading all changelogs i think no.

I am no expert but I had some issues with 6.45.8 (Long-Term version) as well on my CAPsMAN & CAP setup. However, I found 6.46.5 (Stable) working fine on my setup. I have 6.46.5 running over the last couple of weeks with no apparent issues. The relationship b/w long-term and stable versions does not seem to hold true with these two specific versions as I can see.

We have severals (12) CCR that fails on upgrade. All fails after reboot and it stucks on booting. Making a manual reboot puts device into boot loop.

From my experience as a system administrator, I'd do the upgrading on ONE box first, and see how it performs prior to upgrading the whole lot. It equally applies to my suggestion of 6.46.5 above.

Good luck.

It has been quite a while since the release and initial idea was to skip this release. However when this pandemic forced people to work from home and VPN usage increased dramatically, IPsec policies started to act up weird on 6.44.6 at one bigger customer location main office.

Then we did upgrade to 6.45.8 and this got rid of that problem, but then headaches started, because last 6 or 7 weeks have produced same problem at least for 3 times - some (unclassified as per profiler tool) process takes over one CPU core to full and it stays like that until reboot.

Same thing has happened repeatedly on other location and there it had always resulted on complete loss of static routing - /ip route cache print results an error message. This of course leads to loss of all external and inter-subnet connectivity. Only way to access this runaway device is through IPsec tunnel, which is still fortunately up at that moment - to do a reboot. This can by no means be described as "minor problem"!

As system tools are not able to show more than "unclassified" to describe this rogue activity, there is no other remedy than putting reboot command into scheduler (as preventive measure) and sending supout files to you (which is already done).

Both locations have RB1100x4 as affected devices . All there is to do is wait, because there is no way to manually reproduce the problem...

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

viewtopic.php?f=21&t=160881