Is there a way to remotely upgrade RouterOS and at the same time also apply a new configuration?
I need to upgrade many wireless CPEs that run different versions with slightly different configs, to tne single tested combination of RouterOS version and config, no matter which version was there before (6.x for any possible x, any previous config).
If RouterOS is updated first, it is possible to lose access to the device and then it can’t be reconfigured (for example - superchannel no longer compatible with the selected country, default scan-list no longer includes the channel on which the CPE is currently connected to the AP).
If config is updated first, the new config may be incompatible with the older version due to some missing features (for example - new bridge VLAN implementation, new indoor/outdoor options).
So, this all needs to be done in one step - upload new RouterOS with the new config to replace whatever is there currently, and reboot that will: upgrade RouterOS, reset config to default and apply the new config.
Is this possible? I’m currently doing all of this manually, in small steps separately for each device, which is very time consuming.
If not for any 6.x - which is the oldest 6.x version where something like this is possible? This would at least reduce the number of devices to update manually, only to the older ones.
Upload the *.npk file, upload the new *.rsc file.
Reset configuration with “Run After Reset” (including some delay inserted in the *.rsc), this will include the needed reboot.
WARNING: To be tested !!!
The only way which comes to my mind, but you’d have to carefully test it first:
- download the new routeros
- add a :delay 60s line to the beginning of the configuration script
- save the configuration script to a disc partition where it survives a reboot (depending on router model, it may be the flash/ directory) - e.g. flash/configuration.rsc
- run system reset-configuration no-defaults=yes run-after-reset=flash/configuration.rsc keep-users=yes
Don’t forget that additional dependencies between packages may have been introduced between the currently running version and the new one (e.g., security requires dhcp since it became possible to push routes to Windows IKEv2 client).
Is reset to defaults done after upgrade, so the run-after-reset script runs under the new version? What is the 60s delay waiting for?
Fortunately, all devices have the default “main package” so there should be no issues with dependencies.
Most of the devices where I need to do this are of a few different but quite similar types, a single common config probably should work on all.
Neighbor List sorted by Board Name shows a few hundreds total of these: RBDisc-5nD, RBDisc5nD, RBLHG5nD, RBSXTsq5HPnD, RBSXTsq5nD.
Not sure if the ‘-’ in Disc was due to different RouterOS versions, or different revisions of the device.
There are more, but the few exceptions can be done manually as there aren’t that many (a few “ac” ones - RB911, SXT).
ROS versions are various from 6.40.8 to 6.46.7 (the older the more different the config from what it should be now).
All devices do basically the same things (bridge PPPoE between Ethernet and wireless) but details differ depending on device age.
Long long ago there were no VLANs, later I started to do separate data/management VLANs but that was under the old bridge implementation (bridge between ethernet and one VLAN on wireless); then came the new bridge implementation that made things cleaner but different; most recently came regulatory changes, indoor/outdoor.
Yes, will need a lot of testing first as I don’t want to lose access to any device on customers’ roofs during this time of year.
Thanks!
The sequence is this: ROS upgrade, reset config, reboot, load config script. While at it, I suggest to perform Routerboot upgrade as well (another reboot is required). You can try to add that to configuration script.
As the script is started almost imediately after device start, peripherial devices and interfaces are still being initialized and when script comes to configuring some particular interface the initialization might not finish yet … and script fails (and you have device in need of a visit). If you introduce delay at the beginning of script, you give device drivers time for initialization and script can set everything up.
That’s exactly what you have to test. If that doesn’t work, nothing will.
If the configuration script runs too early after boot, some interfaces may not be detected yet, so the configuration script fails when attempting to configure a “non-existent” object. The 1 minute delay is normally enough to overcome this.
Good news - tested on a “new old stock” SXTsq5 with factory-installed ROS 6.40.8. Uploaded my config script (in flash directory) and 6.46.8, reset config run-after-reset as suggested.
Worked without any delay in the script - log messages show the script started 5 seconds after ether1 link up, so it seems the issue has been fixed (delay not needed, at least on this device).
Then set password, enable ipv6 package, routerboot upgrade, second reboot - manually for now, will try later to script that too.
You can do this in the first step if you upload ipv6-6.46.8-.npk (available from extra packages zip file) together with base package bundle. Or, while doing this exercise: you can unbundle ROS by uploading only packages needed (all packages are in extra packages zip file) … you can save some NV storage on devices (and possibly enable future upgrades on devices with only 16MB of NV storage).