MikroTik

RouterOS version 6.45.9 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.9 (2020-Apr-30 10:25):

Changes since 6.45.8:

*) arm - improved watchdog and kernel panic reporting in log after reboots on RB3011 and IPQ4018/IPQ4019 devices ("/system routerboard upgrade" required);
*) capsman - fixed "certificate" parameter updating on CAP;
*) certificate - fixed certificate verification when flushing CRL's;
*) chr - added support for file system quiescing;
*) chr - enabled support for VMBus protocol version 4.1;
*) chr - improved system stability when running CHR on Hyper-V;
*) console - prevent incorrect type interfaces appearing in command hints;
*) crs3xx - fixed frame forwarding after disabling/enabling bridge hardware offloading for CRS354-48G-4S+2Q+ device;
*) crs3xx - fixed interface statistics for CRS354-48G-4S+2Q+ and CRS354-48P-4S+2Q+ devices;
*) crs3xx - fixed switch rule "dst-port" parameter for IPv6 traffic on CRS305-1G-4S+, CRS326-24G-2S+, CRS328-24P-4S+, CRS328-4C-20S-4S+, netPower 15FR devices;
*) crs3xx - improved SFP+ DAC cable initialization for CRS326-24S+2Q+ device;
*) defconf - added welcome note with common first steps for new users;
*) discovery - do not send CDP and LLDP packets on interfaces that does not have MAC address;
*) health - fixed maximum SFP temperature reading under '/system health' menu;
*) hotspot - fixed redirect to log in page (introduced in v6.45);
*) ike1 - rekey phase 1 rekeying as responder for Windows initiators;
*) ipsec - improved system stability when handling fragmented packets;
*) led - added "dark-mode" functionality for CRS105-5S-FB;
*) lte - added "phy-cellid" value support for LTE-US;
*) lte - fixed IP type selection from APN on RBSXTLTE3-7;
*) lte - improved system stability when performing firmware update on R11e-LTE6;
*) sniffer - fixed minor typo in "host" menu;
*) snmp - fixed "ifSpeed" reporting for tunnel interfaces;
*) snmp - fixed "routeros-version" value returning from registration table;
*) snmp - fixed UPS battery voltage value scaling;
*) ssh - added support for RSA keys with SHA256 hash (RFC8332);
*) system - correctly handle Generic Receive Offloading (GRO) for MPLS traffic;
*) system - improved system stability when forwarding traffic from switch chip to CPU (introduced in v6.43);
*) system - improved system stability when receiving/sending TCP traffic on multicore devices;
*) traceroute - improved stability when invalid packet is received;
*) webfig - added default configuration confirmation window to WebFig;
*) webfig - allow skin designing without "ftp" and "sensitive" policies;
*) webfig - do not show WebFig menu when opening 'Check For Updates' in Quick Set;
*) winbox - added "Options" parameter support for DHCPv6 client and server;
*) winbox - added 160Mhz extension channel support for CAPsMAN;
*) winbox - added support for "Tools->WoL" menu;
*) winbox - do not show "Revision" parameter under "System/RouterBOARD" menu on devices that have only one revision;
*) winbox - fixed "ARP" parameter inheritance from "CAPs Configuration" configuration;
*) winbox - fixed "Bands" parameter display for LTE interfaces;
*) winbox - fixed "DSCP" parameter value setting;
*) winbox - fixed "Frequency" and "Secondary Frequency" parameter inheritance from "CAPs Channel" configuration;
*) winbox - fixed "Passthr. MAC Address" parameter display "LTE APNs" menu;
*) winbox - fixed "Switch" menu on CRS354-48P-4S+2Q+;
*) winbox - fixed "dst-port" unsetting in "IP->Hotspot->Walled Garden" menu;
*) winbox - fixed "invalid" flag presence under "System/Certificates/CRL" menu;
*) winbox - fixed automatic "IPv6->Firewall->Address List" table update;
*) winbox - increased limit of multi-entry fields to 100;
*) winbox - made "none" the default value for "Security Profile" parameter when creating a new "Wirelees->Connect list" entry;
*) winbox - renamed "Memory used" to "HDD used" for HDD type under "Tools->Graphing->Resource Graphs";
*) winbox - renamed "Routerboard" to "RouterBOARD" under "System/RouterBOARD" menu;
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) wireless - added "skip-dfs-channels" parameter;
*) wireless - allow using FCC "U-NII-2" frequency range for hAP ac2 and RBwAPGR series devices;
*) wireless - fixed default "antenna-gain" setting on SXT 2 devices;
*) wireless - improved 5GHz interface stability on RB4011iGS+5HacQ2HnD and Audience;
*) wireless - improved compatibility for "ETSI" wireless country profile;
*) wireless - improved system stability on hAP ac^2;
*) wireless - updated "bangladesh" regulatory domain information;
*) wireless - updated "indonesia4" regulatory domain information;
*) wireless - updated "south africa" regulatory domain information;

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.

Skins in web-interface stopped working after upgrading to 6.45.9. Checked on 2 different architecture routers.
If the skin is assigned to a specific group (read only for example), a user of this group after login to web interface will see all elements, even the ones that were deselected in skin. If the skin is selected manually in Design Skin menu, everything looks ok for this user.

Is it just for us or not?

*) chr - fixed graceful shutdown execution on Hyper-V (introduced in v6.46);

How comes 6.45.9 contains a fix for something introduced in 6.46? In case the bug was "backported" from 6.46 it would be good to know what 6.45.x versions are affected.

*) chr - fixed graceful shutdown execution on Hyper-V (introduced in v6.46);

How comes 6.45.9 contains a fix for something introduced in 6.46? In case the bug was "backported" from 6.46 it would be good to know what 6.45.x versions are affected.

There's obvious probability of it being present at least in 6.45.8 as it was released after 6.46. Then again as 6.44.6 was released before 6.46, so it is quite probable, that 6.45.8 is the only one affected in long-term tree - presuming "introduced" is pointing to right version...

*) chr - fixed graceful shutdown execution on Hyper-V (introduced in v6.46);

How comes 6.45.9 contains a fix for something introduced in 6.46? In case the bug was "backported" from 6.46 it would be good to know what 6.45.x versions are affected.

Sorry for the confusion. The fix was backported to 6.45.9 by mistake, but the fix does not cause any harm. There is no issue with shutdown execution on Hyper-V before 6.46. I will remove the entry from changelog.

Sorry, but are where any news about OSPF stability in this release?
Especially with OSPF MD5 auth...

Someone tested this on ARM platform yet? hAP AC2 ? How is compared with 6.45.6 Stable for ex?

Updated one of my hap ac² which is used as a switch and AP. No issues so far, I'm getting ~300 Mbps TCP download speed on a 5GHz 2x2 device while it used to be in the 200-250 Mbps range before (6.45.8 long-term). Still not as fast as the competition, but it looks like an improvement.

Is that with or without capsman? What's your result with a single TCP stream?

hAP ac² + Dell Vostro 7590 (Intel® Wireless-AC 9560)

What meen this? I dont understand.. Improvment or downgrade from what version? Explain.

What meen this? I dont understand.. Improvment or downgrade from what version? Explain.

Clear improvement regarding LT 6.44.6

Upgraded my hAP ac2. All seems fine. Not experienced issues. Seems stable.

Long-term v6.45.9 broke both 2.4 and 5GHz wifi on wAP ac (RBwAPG-5HacT2HnD). It simply refuses to boot up after Netinstall.
Repeated Netinstall process produces same result.

Back down to Stable V6.46.6, and it's working again.

(My wAp ac running as CAP under RB493G as CAPSMAN. Have not been able to upgrade firmware on wAP ac except via Netinstall).

MTeeker That must be something specific to your particular unit. We have 8 wAP ac units here also running as CAPs, successfully upgraded all of them to 6.45.9 from 6.45.8 two days ago (both RouterOS and RouterBOOT), no problems so far.

You wrote "Back down to Stable V6.46.6", so I guess you tried switching to 6.45.9 from 6.46.6. Do you have RouterBOOT also upgraded to 6.46.6?

MTeeker That must be something specific to your particular unit. .....

.... Do you have RouterBOOT also upgraded to 6.46.6?

It's good to know that it only happened on my box, given your successes on eight other wAP ac's.

As a matter of fact, I upgraded routerBOOT to 6.46.6 earlier when I flashed v6.46.6. RouterBOOT remained 6.46.6 when I tried 6.45.9. Not sure if this was the cause of my failure.

Lastly, are you able to upgrade firmware on your wAP ac normally. For some reason, I have not been able to. Henece Netinstall. And I have not been able to find out why.

Regards,
MTeeker

Lastly, are you able to upgrade firmware on your wAP ac normally.

Absolutely. Upgraded RouterOS on all 8 units from CAPsMAN, and once they all came back online rebooted once again to upgrade RouterBOOT (they all have /system routerboard settings set auto-upgrade=yes). All went smoothly.

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Do you test it for OSPF problems or no? I don`t understand.

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Do you test it for OSPF problems or no? I don`t understand.

Busy testing at the moment to see if I can reproduce the issue that happened in 6.44.6 on 6.45.9
We had routers with adjacency for weeks running that would all of a sudden start acting up.

Long time ago, Long Term / Bugfix channel really good for mission critical system, because its already stable n tested. But now LT channel is just a name. In fact, the only latest real stable LT is 6.43.16. So why MT create LT n Stable channel if both unstable just like Testing channel?

Long time ago, Long Term / Bugfix channel really good for mission critical system, because its already stable n tested. But now LT channel is just a name. In fact, the only latest real stable LT is 6.43.16. So why MT create LT n Stable channel if both unstable just like Testing channel?

+1

That's why Mikrotik must stop prevent users downgrading ROS version!

That's why Mikrotik must stop prevent users downgrading ROS version!

Do they prevent? (O_o)

Mikrotik have to choose between being enterprise os which is offering stability, or soho os which is offering alot of features but unstable.

Mikrotik always, I mean always, sell new hardware before make the software for it. Everytime we buy new hardware, we must wait for about 6 months before that hardware can be stable. After that hardware become stable, next version can be unstable again. Man, do u guys sell hardware for business/enterprise or soho/toys?

That's why Mikrotik must stop prevent users downgrading ROS version!

Do they prevent? (O_o)

Yes they prevent. I was working alot with RB951UI-2HnD with the most stable ROS 6.32.4. After some times, MT put factory version. Since that time, RB951UI-2HnD that I bought with factory version post 6.32.4 can't downgrade to 6.32.4. Netinstall prevent it. I was curious, I disassembly older n younger hw, n they both have exactly the same hardware. They prevent downgrade for what purpose?

I disassembly older n younger hw, n they both have exactly the same hardware. They prevent downgrade for what purpose?

Did you contact support with this question?

Mikrotik have to choose between being enterprise os which is offering stability, or soho os which is offering alot of features but unstable.

The features can be in packages. Enterprise is not forced to install them.

Mikrotik have to choose between being enterprise os which is offering stability, or soho os which is offering alot of features but unstable.
...

In a fast changing IT landscape, rigidity in approaching marketplace is not considered a smart strategy for any business. That's given. Enterprise-class products are are more stable because of their better specs, longer development and testing time. And more expensive, as a result.

On the other hand, MikroTik would not be where it is today without having been accepted in many many developing markets as best value products at selling price points.

That somehow reminds me of a car analogy. Lexus cars are better quality and more reliable than Toyota ones. They are both manufactured by the same company.

My point: there is a trade-off in there when using MikroTik products. Some time the trade off may be a bit too much. Sure. But that should not invalidate its strategy.

P.S. I put on my former business analyst hat to offer no more than a bird's eye viewpoint. Wishing you a good day.

When they create CCR n CRS, that time they aim for enterprise router. But guess what? There are alot of CCR n CRS problem caused by software. After sometime, they can make a good software for CCR n CRS, but the next update will be unstable again.

I was working with CCR n CRS for a big factory. I ordered the latest CCR n CRS model but because it's really unstable, the boss dont wanna know any reason, i had to change to PC with x86 MT n HP switch. I lost my money for buying that CCR + CRS. I wait for long time before they can be stable n I can sell it to another factory. But when new bugfix update come n unstable, the boss dont wanna know if its software problem. I offer to revert to previous software version but he said its a bad product. He cancel my last payment because of that. Since then, I dont wanna use new MT hardware. They just give a big headache.

Sorry to hear you lost money over the purchase of some MT gears which had issues at implementation time.

I stopped wondering why tradesmen (such as plumbers and electrical device installers) prefer to work on products on which they had plenty of experience, rather than others. It was after I experienced a moment or two of 'not sure why' as answers to my clients.

Since then, I always try to implement products that I am reasonably sure of their functionalities and reliability for my clients. After all, they rely on my knowledge, however limited it was. Once or twice, I bought new products, set them up and had them running in my lab prior to installing it at client site.

It's fail-safe approach for me.

My two cents. Cheers.

I disassembly older n younger hw, n they both have exactly the same hardware. They prevent downgrade for what purpose?

Did you contact support with this question?

Mikrotik devices can't be downgraded below factory-software version, which is the current ROS version at the time of manufacture.

rb4011igs. after update, bridge mac address changes non stop
my log filled with version 6.44.6 don't have this problem

rb4011igs. after update, bridge mac address changes non stop
my log filled with

Code: Select all

"bridge" mac address changed to xx:xx:xx:xx:xx:xx

version 6.44.6 don't have this problem

Always set an admin mac address for bridges, or it will cause trouble sooner or later. Just my experience..

Here we go again with another long-term headache...

Hopes for thew solution to 6.45.x + RB1100x4 problem have been destroyed again. First testing produces loss of internal DNS resolution and therefore DNS server settings propagation through DHCP also stopped working - and that with /ip dns set allow-remote-requests set to NO!

This means, that even 7 day interval for scheduled reboots is too long - as failure occured on 6th day...

The only thing I can maybe add .If you guys do a security update like 6.44.6 only put in the security update and leave further upstream patches to a following update , so we don't have to choose between security and stability.

rb4011igs. after update, bridge mac address changes non stop
my log filled with

Code: Select all

"bridge" mac address changed to xx:xx:xx:xx:xx:xx

version 6.44.6 don't have this problem

Always set an admin mac address for bridges, or it will cause trouble sooner or later. Just my experience..

ah, it works!
thank u

The only thing I can maybe add .If you guys do a security update like 6.44.6 only put in the security update and leave further upstream patches to a following update , so we don't have to choose between security and stability.

6.43.16 was released exactly one year ago and it was about last long-term release, which had none of the problems 6.44.x and 6.45.x release tree had introduced.

With 6.44.x we got huge increase in DFS radar detections making some of 5 GHz frequencies essentially unusable and some of RB3011 devices started having spontaneous reboots.

6.45.x gave big headaches to al21400 devices and state of DFS radar detections remained about same as before. Only thing to hope is that 6.46.x long-term will turn out better than last 10 months of long-term releases have been giving us...

need to fix this small cosmetic problem. it seems introduce on 6.45.8

Paul

and this bug has not fixed yet..
i found this on my RB4011iGS+5HacQ2HnD-IN and audience; the problem only for radio 5GHz card

Paul

Well... I am not sure how can this get more embarrassing, than it already is...

Two diffenrent locations, both have RB1100x4, one has 6.45.8 and other has 6.45.9.
When CPU usage goes crazy and internal DNS resolution stops working, I try to make supout.rif and guess what? It is not possible, because process stops somewhere about 56% and I get disconnected. Another try gives same result. No desire to try this repeatedly as there's no guarentee about device being accessible after this. Reboot gets rid of the problem, but there's no use of making supout file after that.

What the hell is going on?

P. S. There's no easy way to access device physically on the location if somebody would try to suggest use serial connection.

Looks like "Restore default config" functionality is broken on my hap lite on this version. Getting no config at all after the reset.

Hello.
How fix memory leak on my hAPac2 6.45.9?
just 7 days uptime, free memory down from 80Mb to 65Mb

just 7 days uptime, free memory down from 80Mb to 65Mb

That is not an indication of memory leak on its own. Does the memory usage keep growing? How does it look over time? Do you have a graph to show?

just 7 days uptime, free memory down from 80Mb to 65Mb

That is not an indication of memory leak on its own. Does the memory usage keep growing? How does it look over time? Do you have a graph to show?

- about 80Mb free memoy after reboot and still decreases every day by ~2-3 MB. It's happens once per day, not each minute.
- i'm think that graph doesn't work properly cause it's empty

- i'm think that graph doesn't work properly cause it's empty

You have to enable resource graphing by adding a new rule under "Resource Rules" tab.

What the hell is going on?

Well... I can tell you what is going on - I did a reboot after making supout proved to be impossible and some hours after that it left THIS in LibreNMS log and surprise, surprise - it really shows just that Is this one also one of these "cosmetic" issues or is 6.45.x crippling 1100x4 and 4011 devices? Fancy a RMA? If device has been in use for years (factory software 6.40.4)?

What next?

@nmt1900 seems this device is still running 6.45.8

Yes it was. As I stated previously, we have 3 1100x4 devices with 6.45.8 and 6.45.9 and they all suffer from same problems to somewhat different extent. Others with 6.44.x versions are functioning without problems.

As update to previous - another reboot "brought" license back and this device now also is updated to 6.45.9. It is interesting to see, which would license level be after next reboot - almost like rolling a dice. This is getting really confusing...

Hello.
How fix memory leak on my hAPac2 6.45.9?
just 7 days uptime, free memory down from 80Mb to 65Mb

No memory leak for me at all.. Memory usage seems the same like every previous build i have used before, no matter that is stable or long term one.. Currently on latest long-term, all seems fine, 10 days till now.

Now we know, how this starts.
This pops up in log and after that CPU usage goes up and stays there. More than one thing ceases to work after that - commands in terminal produce similar output with suggestion to send supout file.

The license level problem is also related to that because issuing /system license print also puts out similar error message in terminal and "adding insult to injury" - finally new terminal window refuses to open in winbox.

We'll see if supout can be made with scheduler or not, but after that attempt it is time to downgrade.

After 11 day uptime after flashed this long-term build.

- No memory leak. Still memory is the same !
- No licence Level issues reporeted before for my hAP AC2.

For people who is reported issues. Make sure that you update RoS and Firmware too to latest available compatible to RoS version.

Does anybody check ospf problem?

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Hi, do you test OSPF issues yet? Any positive news?

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Hi, do you test OSPF issues yet? Any positive news?

Passed lab test with a couple of Ubnt and Cisco equipment . Going to go put it in a non critical area of the network with and see how it goes .
Not very optimistic as I've seen nothing in the changelogs indicating any sort of fix.

Hi,
I will test now on several non critical devices too.
For now - we have no large scale up/down events on core routers with many circuits, so no statistical data on ospf behavior.
I will inform on issue detection.

But it is true - no news on ospf fix in changelog.

Gonna throw this up in the lab but any updates on the weird OSPF issues that were introduced 6.44.6 and upwards ? We had to go back to 6.44.5 as we'd get adjacencies seemingly stuck . Only thing that brought it back was either disabling/re-enabling the instance or rebooting the router.

Hi, do you test OSPF issues yet? Any positive news?

Passed lab test with a couple of Ubnt and Cisco equipment . Going to go put it in a non critical area of the network with and see how it goes .
Not very optimistic as I've seen nothing in the changelogs indicating any sort of fix.

Seems random reboots disappeared on HAP AC^2 with 6.45.9.
Uptime is 8 days.

Skins in web-interface stopped working after upgrading to 6.45.9. Checked on 2 different architecture routers.
If the skin is assigned to a specific group (read only for example), a user of this group after login to web interface will see all elements, even the ones that were deselected in skin. If the skin is selected manually in Design Skin menu, everything looks ok for this user.

Is it just for us or not?

+1
Not just you. Busy deploying The Dude and wanted to create web skin for web access to The Dude this eve and noticed exact same as described

Someone needs to tell Mikrotik that there is a bug in OSPFv3 (tested in 6.44.5, 6.44.6 and 6.45.8) when the router is experiencing high IPv6 traffic (1.5gbps here started to give problems). It is that bug that some complained about in the forum, the adjacency drops, and only goes back until the router deactivates and reactivates the instance of OSPFv3, while OSPFv2 does not present any problems. I believe it is possible to reproduce this bug by closing adjacency between some routers and leaving them with about 5gbps of IPv6 traffic (or more) for at least 2 days.

Yes, I already opened a ticket on the support, I talked a lot with them, and the conclusion I reached was this. Nothing to complain about support, there is only one problem and needs to be fixed. I still need to test version 6.45.9, but by the changelog, it should be the same.

Someone needs to tell Mikrotik that there is a bug in OSPFv3 (tested in 6.44.5, 6.44.6 and 6.45. when the router is experiencing high IPv6 traffic (1.5gbps here started to give problems).

You can do that: support@mikrotik.com

You can do that: support@mikrotik.com

The bug is already reported to Mikrotik support. Do not want to lose sleep over this issue, I'm leaving for another manufacturer to rule my network core. I helped with sniffer, with data, prints, tests, in short, everything that was within my reach.

I hope that Mikrotik will be able to reproduce and fix the bug.

RouterBOARD 1100x4
factory FW 3.43.2
Upgrade from 6.44.6 to 6.45.9 - random reboots every 5-7 days (
On 6.44.6 some months before - newer reboots.


RouterBOARD 1100x4
factory FW 6.43.16
Upgrade to 6.45.9 - no reboots....

@alexkv: why don't you upgrade RouterBoot on both units? It is adviseable to do so every time one upgrades RouterOS.

/system routerboard upgrade .. and reboot after that.

We'll see if supout can be made with scheduler or not, but after that attempt it is time to downgrade.

This is really interesting. I provided Mikrotik with needed information and my support ticket got this answer: "your device has a hardware malfunction. Please submit the device for warranty repair - if warranty is still valid".

I did a full rollback to 6.44.6 and now there is about 4 weeks of uptime without any problems whatsoever.

What kind of a "hardware malfunction" might it be if it disappears after firmware downgrade???

I did a full rollback to 6.44.6 and now there is about 4 weeks of uptime without any problems whatsoever.
What kind of a "hardware malfunction" might it be if it disappears after firmware downgrade???

.
ROS v6.44.6 was my preferred firmware on RB1100AHx4 but reboots after 20-30 days continued. Mikrotik analyzed the supout and responded the same, hardware issue please return.

cAP ac upgrade from 6.44.6 to 6.45.9 (including firmware)

Bug found:
- I was not able to connect the device via OpenVPN anymore after upgrade using HTTP of WINBOX
- Some services are suddenly down (Status "down" in Dude: Probe, CPU, HTTP, ping, router management, SSH)

Issue mitigation / workaround:
- Downgrade back to version 6.44.6

No issues on hAP ac, hAP ac^2, PWR-LINE AP (all of them are monitored the same way - Dude via OpenVPN)
Support contacted.

Anyway that someone report problems with this version, for me seems very stable firmware.

Upgraded two of my LTAPs from 6.44.6 to 6.45.9 and LTE stops working. On status tab it says a sim is not inserted...... roll them both back to 6.44.6 and LTE works great again. Any ideas?

Hello,

I cannot downgrade CRS354-48P-4S+2Q+RM to this version from version 6.47.
Why?


Thank you.

Best Regards,
Sebastijan

The answer is in Log.

I did a full rollback to 6.44.6 and now there is about 4 weeks of uptime without any problems whatsoever.
What kind of a "hardware malfunction" might it be if it disappears after firmware downgrade???

Now it is 48 days without any of these problems that necessitated scheduled reboots every 3-5 days to be able to maintain normal network functionality.

"Hardware malfunction" which seems to miraculously disappear after downgrade? This does not seem to add up...

I'm having a possible memory leak in a Routerboard 960PGS. I'm doing dynamic routing with OSPF and a couple of day ago after configuring MPLS the memory usage started to go up and crashed the router.

If I disable MPLS the memory usage stops growing but it never get cleaned, the only way to free memory is to reboot the router.

Make supout.rif when memory usage is high and send to support@mikrotik.com

Found a small bug in the user interface, present in 6.45.9 and at least the one before as well. When you select "N/AC" as wireless band, under "HT" the fields for AMSDU settings get greyed out and aren't editable anymore. This is only the case for "N/AC", and just "A" of course which doesn't have block acks at all, so there it makes sense.

The bug is present in both current Winbox 3.24 as well as Webfig and has apparently already been fixed as of current stable 6.47.1. Would be great if you could just backport the fix into the long-term branch soon.

As there is no newer long-term version available yet, there is more about this one.

The problem I had was 1100x4 devices "going mad" with scheduled reboots as only workaround.

Today I found out one more thing about this problem: when device is at 100% CPU and connection to winbox service is not possible, I got in by means of SSH. Then I tried to enable and disable other services like www and telnet. Everything responded as expected, but THEN I tried to disable winbox service and the command hanged with control+C as only way out. There was no way to control winbox service and it was not accessible either - with CPU at 100% all the time.

Luckily it was possible to reboot the device from ssh interface and after that everything was normal again - until next time probably. It remains to be seen, what will be the way out of this situation...

6.45.9 (and 6.45.8) has a bug in DHCP+Radius: when client requests IP that doesn't belong to DHCP server pool (for ex., 192.168.0.100 when client connects his PC to WAN cable instead of his router's LAN) - DHCP server accepts it and sends request to radius with this IP. and then - assigns requested IP to client (of course, it doesn't work). 6.44.x and earlier works OK. Support doesn't helped - looks like support has no hardware to reproduce this bug (it's 100% reproducible)

Also, on 6.45.9 dynamic address list items (specified in Radius 'Mikrotik-Address-List' attribute) sometimes doesn't be dropped when lease is expired.

Try upgrading winbox to the latest version..

Installed on a number of units to notice that the Hotspot Host table is now empty. It appear the Hotspot is still working as clients are able to connect and logon and then appear in the active table.
Seen this on all platforms. Also same issue is present in v6.47.2
Is it just me or is anyone else seeing this?

Installed on a number of units to notice that the Hotspot Host table is now empty. It appear the Hotspot is still working as clients are able to connect and logon and then appear in the active table.
Seen this on all platforms. Also same issue is present in v6.47.2
Is it just me or is anyone else seeing this?

If this is with Winbox 3.25 try older Winbox version.

Installed on a number of units to notice that the Hotspot Host table is now empty. It appear the Hotspot is still working as clients are able to connect and logon and then appear in the active table.
Seen this on all platforms. Also same issue is present in v6.47.2
Is it just me or is anyone else seeing this?

If this is with Winbox 3.25 try older Winbox version.

Many thanks, didn't consider it could be an issue with Winbox. It is indeed an issue with Winbox 3.25

When will be released fix for CVE-2020-3702 in long-term ?

When will be released fix for CVE-2020-3702 in long-term ?

+1

When will be released fix for CVE-2020-3702 in long-term ?

Waiting for it too

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

viewtopic.php?f=21&t=166153