RouterOS version 6.47.4 has been released in public “stable” channel!
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
Device has enough free storage space for all RouterOS packages to be downloaded.
What’s new in 6.47.4 (2020-Sep-16 11:32):
Changes in this release:
*) bridge - fixed STP alternate and backup port states for devices with switch chip (introduced in v6.47);
*) crs3xx - fixed IGMP snooping for CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed switch port “egress-rate” removal for CRS305, CRS326-24G-2S+, CRS328, CRS318 devices;
*) fetch - fixed “src-address” usage for SFTP;
*) filesystem - improved long-term filesystem stability and data integrity;
*) hotspot - ignore packets from host while MAC authentication is in progress;
*) kidcontrol - fixed “time-unlimited-rate” to engage in correct time;
*) smb - fixed possible memory leak (CVE-2020-11881);
*) sms - fixed SMS sending when both “interface” and “smsc” parameters are specified;
*) snmp - fixed “/tool snmp-get” functionality (introduced in v 6.46beta43);
*) user-manager - updated PayPal’s root certificate authorities;
*) wireless - added support for U-NII-2 for wAP ac;
*) wireless - updated “canada” regulatory domain information;
*) wireless - updated “united states” regulatory domain information;
To upgrade, click “Check for updates” at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device
Please keep this forum topic strictly related to this particular RouterOS release.
On the version 6.47.4 command repartition (e.g. “/partitions repartition partitions =2”) causes the router’s cyclic reboot (about every 10 seconds). On versions 6.47.x situation the same.
Reset didn’t help, I’ve been able to repare it only with netinstall
On the version 6.46.7 this command works correctly
One of my CCR1009’s appears to have developed a memory leak. It had been running 6.47 and and uptime of 3.5 months and yesterday it crashed due to kernel fault, out of memory.
As there was a network interruption anyway I upgraded it, to 6.47.3 as that was the newest available yesterday, and now I see it is steadily using up memory again.
In 11 hours of uptime it went from 275MB used (typical for this router) to 535MB used, or about 23.5MB per hour.
(I am used to some memory usage increase that first increases more rapidly and than flats out but not to this level)
Can this be caused by the problem fixed in this release? (i.e. has it been released now due to reports like this from the field?)
I am not using SMB on this router and it has been firewalled. Can that bug still lead to this memory use?
If not, how can I debug this? I don’t think it is due to a configuration change, more likely due to some new (exploit?) traffic that causes this.
I took a supout.rif and uploaded it to the mikrotik.com site, but how can I find from that info where all this memory is being used?
Same with my Hap Ac2 actually. It was slowly developing a memory leak. From 80MB to 55 and it still going. After i restarted the mikrotik, things work fine then cycle repeats.
After upgrade from 6.47.3 my device stopped working. I was not able to connect over ethernet or WiFi. Even after restore config. I had to do netinstall. Then router booted again. But it is shame, that standard tools like restore backup or restore from RSC does not work. I have tried with releases and backups from 6.47.2 to .4 but I was not able to restore config from backup or RSC. Even reset configuration with option run ater reset does not work. It is even not possible to copy/paste whole export config, I had to copy paste config manually by 20-30 lines.
However, I’ve done a couple of tests trying to upload/download some files to/from a server and I’m getting really low transfer speeds (~100KiB/s). Has anyone experienced the same type of behavior?
No I don’t use it. The router has standard DNS servers and barely uses DNS at all. (it is not a resolver for other systems in the network)
In the meantime I have discovered that another router which is on the same segment has a similar behavior, but there it does not consume memory all the time but in few-hours-no few-hours-yes cycles. I am waiting for an interval where the memory usage rises, as that 2nd router has far less traffic so I can observe if there is unusual traffic incoming.
I have located the problem and will inform MikroTik in de support case I had opened for it. It happens to be another DNS resolver bug (not DoH related).
An ipipv6 tunnel problem remains in 6.47.4. When pppoe client disconnect and then reconnect, ipv6 address of device is changed , but local address of ipipv6 tunnel is not changed (ipv6 firewall connection print), and the tunnel is down actually.
I didn’t configure “local-address” value. I think it should be changed automatically. Please fix it.
My config:
[admin@MT] > int ipipv6 print detail
Flags: X - disabled, R - running
0 R name="v6tun" mtu=auto actual-mtu=1440 local-address=::
remote-address=xxxxxxxxxxx.sn.mynetname.net
current-remote-address=240e:3a1:1234:5678::1
dscp=inherit clamp-tcp-mss=yes
It’s not directly related to this release (or is it?). This is the first release that cant fit in 16mb device (no extra stuff in the flash, no log files, nothing…). So I’ve upgraded using netinstall which is pain in the …
Some devices with 16mb flash will never be able to update without netinstall… (for example RB941-2nD).
Maybe it would be a good idea to have minimal version without some tools (available in packages on demand). Less experienced users are basically denied from auto upgrades right now and it creates extra security risk for them.
It is caused by the combined package. That was a dumb idea that never should have been introduced. Before that, you could just delete unneeded packages, now you can only disable them but they still take space.
When you have this issue, see which packages you need, one time download the zip file with all packages and upload only the needed packages to the router.
(e.g. system, advanced-tools, dhcp, ppp, wireless)
(first you can experiment with the combined package and disable all things you think you don’t need (mpls, hotspot, routing etc) and see if all still works OK)
Then when you have uploaded the separate packages, reboot the router and only those packages will be installed and you have more space and require less for the upgrade. So automatic upgrade again works as before.
I happen to have another router on the same network and it had the same problem. That is a CHR with a lot less memory so it crashed a lot sooner.
As this router does not pass that much traffic as the CCR (it was originally installed to run Dude but I don’t use that anymore, but the router remains as a backup to access the main one via MAC when it should be required, and I also use it for testing config experiments) I could observe the network traffic and see what scenario caused it.
I rather not publish the actual scenario until it has been fixed, as it can be abused by some people who want to remotely crash a router.
Something has beed wrong with Dude beginning from some earlier 6.47.x version. Constant “connection reset by peer” and another errors of similar kind.
Now I accidentally happened to see, that after these errors SD card is not visible in System → Disks window and command /disk print shows only partial information (name and free space information missing), but this returns to normal immediately after Dude server is stopped. It looks like Dude server is screwing something up with storage when running. That might actually explain these connection errors and Dude sessions crashing etc.
It does not have to do with the current SD card itself as the card is checked with the computer and reformatted. Then I tried to use another “fresh out of the box” SD card and exactly same scenario occured again.