v6.49.2 [stable] is released!

RouterOS version 6.49.2 has been released in public “stable” 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.2 (2021-Dec-03 14:53):

*) device-mode - improved flagged router configuration detection;

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.

Any other (minor) difference to 6.49.1? I’m wondering if it’s worth upgrading from 6.49.1 if one isn’t interested in this functionality?

Is there a non-dangerous configuration we can add to test the flagging?

Is this version still bricking mipsbe devices, especially SXT’s ? I haven’t dared to upgrade any devices since the 6.49 release broke half my network.

I had some issues upgrading Tile to 6.49.1 (http://forum.mikrotik.com/t/v6-49-1-stable-is-released/153419/136)
Are there any changes in the RouterBoot code that might help me in 6.49.2

Same as with 6.49.1:
Upgrade to 6.49.2 resulted in a boot loop of hEX S (RB760iGS, mmips).
No access to device was possible until Netinstall, which solved the issue.

Ouch… the routerboot fix should have been in this version, it’s rather important!

regarding flagged from wiki:

“RouterOS employs various mechanisms to detect tampering with it’s system files”

How that has been done, give us an e.g.

After upgrading to 6.49.2 The Dude stopped working for me. I also noticed that I am unable to upgrade to 7.1 as it just sits on calculating download size. Are both of these bugs or just weirdness? I typically don’t upgrade this close to releases but was looking to try out wireguard.

Can you check if the Dude package is installed? Can you check from Winbox if Dude is running? Have you updated your Dude client(in windows you need to do a ‘run as admin’)? I have upgraded to 6.49.2 and dude runs.

But I have another regression. After updating to 6.49.2 my test RB1100AHx4(dude edition), it deleted my user and enabled the default admin. The rest of the config is still there(I think).

Hi kehrlein,

I tried to repeat the same problem on our hEX S, but did not see any boot loop after the upgrade.

Did you already report this to support, do you have a SUP ticket number?

Some other questions that might help us identify the problem:
Did the device successfully upgrade to 6.49.1 or 6.49.2, or did the boot loop only start after the RouterBOOT upgrade (after the second reboot)?
What RouterOS (/system resource print) and RouterBOOT (/system routerboard print) versions were installed before the upgrade?
What configuration was used on the devices?
Were there any SFP or USB devices connected?
Can you repeat the problem?

I would appreciate it if you could share as many details as possible, so we could recreate the same problem in our lab.

Maybe some config is causing that HEX S keeps stuck after upgrade.

I suggest post your configs to do the respective tests.

Today I will upgrade a HEX.

Regards.

My issue with 6.49.1 is here: SUP-67276

Mine was Tile - No sfp modules installed on the ones I tried. (CCR1036).
Recoverable with a console cable, but no good if remote.

Did the device successfully upgrade to 6.49.1 or 6.49.2, or did the boot loop only start after the RouterBOOT upgrade (after the second reboot)?
Yes! - this was exactly it - details in the ticket.

I was really hoping that 6.49.2 might solve it.

Mike

Someone tested on SEXTANTs devices? We throw away about 10 units with the old 6.49.1 because the update bricked those devices. Thanks

Hi EdPa,
thanks for your reply!


Created SUP-68147 right now. Let me know if you need further information.


Due to an automatically script for firmware update, I can’t say if the issue occured after installing the software or the firmware.


6.49.1 both


No.


I’ve tried to repeat the problem with another hEX S (identical config) but in this case, the update of Soft- and Firmware was ok.




/interface bridge
add admin-mac=42:8F:5A:12:AB:12 auto-mac=no frame-types=admit-only-vlan-tagged ingress-filtering=yes name=bridge1 pvid=999 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="Uplink"
set [ find default-name=ether2 ] comment="Samsung TV (private)"
set [ find default-name=ether3 ] comment="Yamaha (private)"
set [ find default-name=ether4 ] comment="unused (private)"
set [ find default-name=ether5 ] comment="unused (guest)"
set [ find default-name=sfp1 ] disabled=yes
/interface vlan
add comment="private for Mgmt" interface=bridge1 name=bridge1_vlan2 vlan-id=2
/snmp community
set [ find default=yes ] addresses=192.168.3.60/32 authentication-password=xxxxxx encryption-password=yyyyyyy security=private
/system logging action
set 1 disk-file-count=3 disk-lines-per-file=10000
/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether1 pvid=999
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether2 pvid=2
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether3 pvid=2
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether4 pvid=2
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether5 pvid=3
/ip neighbor discovery-settings
set discover-interface-list=all
/interface bridge vlan
add bridge=bridge1 comment=private tagged=ether1,bridge1 untagged=ether2,ether3,ether4 vlan-ids=2
add bridge=bridge1 comment=guest tagged=ether1 untagged=ether5 vlan-ids=3
/ip dhcp-client
add disabled=no interface=bridge1_vlan2
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=1122
set api address=192.168.3.60/32
set api-ssl disabled=yes
/ipv6 dhcp-client
add add-default-route=yes interface=bridge1_vlan2 request=address use-peer-dns=no
/snmp
set contact="aaa bbb" enabled=yes location=muc.domain.tld
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=test2.domain.tld
/system leds settings
set all-leds-off=after-1h
/system logging
set 0 disabled=yes
set 1 disabled=yes
set 2 disabled=yes
set 3 disabled=yes
add action=disk topics=critical
add action=disk topics=error
add action=disk topics=warning
add action=disk topics=system
/system ntp client
set enabled=yes
/system scheduler
add interval=1m name=refresh-ipv6 on-event="/ipv6 dhcp-client renew [find interface=bridge1_vlan2]" policy=read,write start-date=feb/13/2016 start-time=20:50:46
/tool romon
set enabled=yes secrets=xxyyzz

upgraded all my devices from 6.491 to 6.49.2 as always with 2nd reboot to upgrade firmware. No problems ...
CCR1009 took 30 sec to flash and reboot, 2nd reboot took less than 15 seconds

Hi,

I recently upgraded from 6.49 to 6.49.2 and noticed that the firewall conntrack entry size has reverted even though the previous release notes state:
" conntrack - increased total connection tracking table size based on installed RAM size;"’

Just as a note all I did was upgrade, the RAM size is still the same.

Here’s a couple screen shots of before and after.
BEFORE 6.49.2
CHR-6.49-Connection Entries.PNG
AFTER 6.49.2:
CHR-6.49.2-Connection Entries.PNG

Does anyone @MT there test this at all before sending it out as a “stable” release??
Please fix this oversight.

I think the wording is a bit misleading here, but probably you see what’s expected. The number of max entries depends on your installed RAM.
Currently you have 3888 items with a maximum of 1048576. This is hardly an issue, no? If it is you have to add more RAM I guess.

I think the determining factor might be free RAM.
What’s the difference between 6.49 and 6.49.2 for that aspect ?

Though I do agree over 1million possible connections can not really be seen as an issue…

Ok, 6.49 had this:
*) conntrack - increased total connection tracking table size based on installed RAM size;
Then in 6.49.1 this:
*) conntrack - limit total connection tracking table size based on installed RAM size;
And since your screenshots are from 6.49 and 6.49.2, I’m assuming there was some error with the change done in 6.49 and corrected in 6.49.1.