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.49rc1 (2021-Sep-23 12:32):
Changes since last beta release:
*) backup - fixed backup file restore (introduced in v6.49beta);
*) branding - fixed LCD logo loading from branding package when installed via Netinstall;
*) branding - properly clean up old branding files before installing a new one;
*) bridge - added IGMP and MLD querier monitoring;
*) bridge - improved stability when quickly adding and removing bridge interface;
*) crs3xx - fixed default MAC address calculation on management Ethernet for CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - improved system stability when learning MDB and FBD entries for CRS312, CRS326-24S+2Q+ and CRS354 devices (introduced in v6.49beta44);
*) dhcpv4-server - reset lease’s dynamic “bcast” flag on packets from relay;
*) gps - improved interface monitoring;
*) health - improved temperature reporting;
*) kid-control - improved IPv6 firewall rule generation;
*) leds - fixed LTE LED default mapping for wAP R ac LTE kit;
*) lora - added additional predefined network servers;
*) lora - fixed “PULL_DATA” token generation;
*) mpls - allow to disable FastPath (CLI only);
*) mqtt - added server name indication;
*) netinstall - require Netinstall version to be the same or newer as “factory-software”;
*) poe - update PoE firmware only on devices that supports it;
*) qsfp - improved system stability when setting unsupported link rates;
*) routerboard - fixed “reformat-hold-button-max” validation for values below 10s;
*) sfp - improved SFP, SFP+, SFP28 and QSFP+ interface stability for CRS3xx and CCR2004 devices;
*) sfp28 - changed FEC auto mode to disabled;
*) tr069-client - fixed traceroute diagnostics time values;
*) tr069-client - improved XML with new-lines for readable output;
*) w60g - limit power output when using region EU to match EN302567 on nRAY;
*) w60g - use EU region by default;
*) winbox - added “dhcp” option to “multicast-helper” setting;
*) winbox - do not allow to add/remove W60G interfaces;
*) winbox - separated CCQ Tx and Rx values in their own unique columns;
*) winbox - show “System/Health/Settings” only on boards that have configurable values;
*) winbox - show “current-channel” column by default for CAP interfaces;
*) wireless - added U-NII-2 support for US and Canada country profiles for hAP ac lite;
*) wireless - do not remove channels >2462 MHz from “scanlist” if scanning for fixed channel;
*) wireless - log client signal strength on disconnect;
*) wireless - updated “israel” regulatory domain information;
In SUP-51076 I am discussing memory leaks in the DNS resolver and was requested to test an internal beta56 which unfortunately was not available in the architecture of my test router.
Now I see this rc1 and this item does not appear in the changelog, also it appears not to be solved (still testing).
I still see the “cache used” in IP->DNS increasing without new items being added in IP->DNS->Cache (but repeated queries being made).
When the cache size limit is reached, I see items disappearing from the list. It looks like there still is a memory leak.
DNS issue is absolutely irritating and its existing in 2+ months of 6.49 releases and was reported so many times by users i just dont get it how was it not fixed yet?
Good to see that the restore of backups is possible again. A very important function when updating to a next version.
I hope that this will be also tested by Mikrotik self, each time a Beta/RC/incremental/main release is made. Not leaving that over to the users, who then are not pleased to go, the long way to restore the config by hand.
On heavy load “30%”!!! on CCR1036-12G-4S (r2) (345 PPPoE sessions)
again this error
snmp,warning timeout while waiting for program 20
ONLY AND EXCLUSIVELY when monitored from The Dude 6.47.10
no other devices allowed to monitor SNMP
SNMP version used: 2 (2c)
After that error the RouterBOARD is less reactive and, on short time, all ways to connect to the RouterBOARD stop working,
webfig, winbox, mac telnet, telnet, SSH (API not tested).
The only ways to reboot is to turn off the power or wait for the watchdog, which is set to reboot immediately,
but fails to reboot the router right away and takes more than 10 minutes.
In meantime between error log and watchdog reboot, all user still working like the RouterBOARD is not “locked”.
Obviously I can not make supout.rif on that moment because I do not reach to access to the RouterOS.
I certainly believe that, however this slipped through for several if not all versions of the current Beta. It is like upgrading the firmware of your Tesla for more functions only to notice that brakes don’t work anymore, because of that upgrade. You can’t go back to a car with brakes or even worse you note then it when you have to slow down the car.
[quote=rextended post_id=882057 time=1632482320 user_id=68609] [quote=durkonos post_id=882053 time=1632481178 user_id=152069]
What about connecting to the router with console cable ? Have you tried that ?
[/quote]
I can’t wait an hour to restore the service, driving 100Km away for test if serial cable work or not…
[/quote]
OOB connectivity is essential for SPs. we even built a dedicated network on different access technology (LTE) to cut down reaction time.
This is OT and, everytime, the topic go OT because someone instead to try to understand the problem,
it suggests other things that have nothing to do with it.
Does putting a backup line prevent the RouterBOARD from giving that error and stop working? (Not, obviously)
I do not wrote about rings, LTE and other than I have onsite because is not that the point and is irrilevant.
And yes, I put that on failovered production machine, because I do not have a lab to replicate 350 true users…
Instead the @durkonos question, is a good question, but I do not have nothing connected on serial console onsite.
Well, when he installs an rc [testing] version on a router 100km away I presume it is more of a hobby SP than some critical thing…
I don’t even do that on our HAMNET!
I think its possible to tell your staff these things on the Mikrotik LAN vice public forum, or were
you simply trying to point out the HUGE improvement over the latest 7.1c release LOL.
I would never have noticed unless you brought it up. ;-PP