How do you upgrade this Mikrotik (double wireless package) ?
I have a hundred plus remote client Mikrotiks with double wireless packages.
All of this started when Mikrotik came out with a separate nv2 wireless package.
It has been hit and miss (99 percent miss) when upgrading these clients.
If they are in-house, I just factory-default reset them.
However, these are remote clients scattered all over the place. And by experience, I know there is a 99 percent chance that upgrading any of these will result in a brick that even net-install can not fix.
So, how can I remotely fix/upgrade without visiting hundreds of client sites? help help help help
Put there only individual packages you need of higher version and reboot. Do not use combined package anymore.
There is no guarantee that the client will successfully connect back when upgraded. I saw situations when such device totally lost its wlan settings, but it was it the days of changing between wireless-fp and wireless-cm2 and pure wireless was returned back. It was nightmare these days…
I guess I am trying to locate or create a Method-Of-Procedure (MOP or SMOP) that can be used to recover/correct remote wireless clients that are in this condition.
I will try recover/correct/fix a few closer customers with this issue.
Two things I think that would greatly help correct this issue would be something like this:
1- On firmware update/reboot, have the new/updates ROS check if there is an additional wireless package and auto-remove it, and bring it back up on-line. Something that could be performed on any older version of ROS on a remote wireless client.
2- (I think this is do-able but I don’t know how) : Create some type of a boot script which does something like this:
2a- Capture the current running configuration
2b- Allow the Mikrotik admin to perform a reset-to-factory-defaults (clear everything and reboot)
2c- Upon reboot, the boot script will auto-reconfigure everything and bring the remote wireless client back up on-line
2d- Have the script use all clear-text human readable & easily editable
I suspect the 2nd possible option could be do-able, but I am not good enough with scripting to this.
One side-benefit of the 2nd option could be as follows:
A tool like this could allow a Mikrotik Admin to have multiple different ready-to-go configurations on a remote wireless Mikrotik. Then a watchdog script could auto-cycle through all of the different ready-to-go configurations by auto-loading a next configuration & reboot every few minutes. The cycle could auto-repeat until the remote admin stops/aborts the process. Something like this could allow an admin to have a remote mikrotik auto-attempt to connect to different things different ways and when the remote admin sees what they want, then they could remote in and stop the process.
But what do I know, I am not scripter - but I do know how to program in BASIC very well and have used BASIC for almost 40 years now - lol
For the condition I have stated in the prior posts on this topic, I have a fix. This procedure worked on a dozen remote wireless client Mikrotiks.
1st - verify the condition:
In winbox - go to System–>–Packages
You will see all the packages on the remote Mikrotik.
Verify the 1st wireless package (the one that is included in the base system is disabled (greyed-out)
Verify the 2nd wireless package (at the bottom) is enabled (not greyed-out )
2nd - up-load the updated ROS into files (do not reboot - yet)
3rd - up-load the optional stand-alone wireless package info files. (same version as the ROS file in step 2 above)
4th - reboot the remote wireless client Mikrotik
5th - when the remote wireless Mikrotik comes back, check System–>–Packages and verify you now only see one wireless package
6th - in Files , delete the wireless-x.xx-npk file
7th - reboot
North Idaho Tom Jones
8th - using “New Terminal” check your /system /routerboard print shows the current-firmware -and- upgrade-firmware both match. If not , then upgrade and reboot.
(I performed this on a dozen or so remote wireless Mikrotik clients, all of them came back on-line and appear to be working properly.
I hope this helps anybody else experiencing this …
North Idaho Tom Jones
EDIT: This procedure appears to also work on Access-Points and both sides of wireless WDS links
If you don’t mind to keep the combined package further… If device supports multiple partitions you can set the script to activate the second partition and reboot to revert all actions back in case you loose the WiFi connection after the update.
Isn’t that the same thing as would happen when you simply clicked “check for upgrades” then “download & install” ??
I think the router would automatically download the required packages (in this case the combined package and the wireless package)
and install them. I have several routers with one or two optional packages and they always get updated correctly.
When I do only the “download”, I see the packages in the files area.
Are you claiming that this method would fail, while your method succeeds?
Ok so when you do update on such an install, the separate wireless package is not automatically downloaded?
You can check that by doing download only, not download & install, and then checking the files section to see what it downloaded.
The above “… click on unnecessary package, select to uninstall it, reboot device …” where I assume you are referring to the optional second wireless package to uninstall (for me) has had a history of loosing the remote client devices , then we have to go out on-site and fix.
That is not surprising. Did you also try to enable the other wireless package (that is disabled in the above listing) before doing the reboot?
It is always tricky. Fortunately in our network we usually have access from the ethernet side as well (because it is a mesh of wireless links so most sites have more than one link).
Still, I had to talk someone through a netinstall one time…
I think I tried everything in every possible order I could think of with this issue on remote wireless clients. (Removing, disabling, mark for removal and mark for enable)
I have also have 4 techs experiencing the same thing , and the only 100-percent reliable method they could come up with was to be on-site and factory default and sometimes netinstall. Well ya can’t do that remotely to a wireless client.
EDIT: FYI I have 30+ bricked mikrotiks which failed attempts at remote upgrades. By bricked - I am stating you can’t even netinstall them. They go into a sustained constant reboot.
In the past I did a couple of “reset configuration” with “keep user configuration”, “no default configuration” and “run after reset” pointing to a /exported file that was slightly edited.
This was on RB2011 routers and it worked fine every time. I did it to make major changes to configuration that I felt uncomfortable making step-by-step (or believed it was not possible).
However, later when I got RB951G routers and slightly newer RouterOS, it happened several times that it did not complete this. And those do not have RS232 and it has been impossible to diagnose what exactly went wrong. I saw others report the same problem. Now, I would not dare to do this on a remote router anymore…
It does not have the same effect. You can download extra packages zip file of higher version, select only packages you need and install them. The system package replaces the combined package so there will be only those packages you want. You will spare space and be able to add or remove whatever you want in the future.
We have identified a bug and it will be fixed. The RouterOS system should ignore the packages that are already in the bundle, even if they are disabled.
Normally you should not combine the separate packages and the bundle.
