That seems like good news — If you can get into the ATL via ssh and 192.168.188.1 - there is no need for going to mast.
No, it’s the opposite. Quoting myself:
I > can’t > ping anything (even the gateway), I > can’t > SSH to the gateway.
And you tried winbox to see if shows up as “Neighbor” with MAC address?
As I said, I use only SSH to connect to any of the routers and all other methods were intentionally disabled for security reasons.
Gotcha. Well, then it’s getting it off the roof/tower to reset it one way or another.
I’ll note at some level, you can get too crazy locking these down…
netinstall-cli is for Linux. Give it a try.
Great news!
I can’t believe it myself but we were able to unmount the ATL and I was able to Netinstall it. Now I can login, I have Internet etc. Still about to re-configure it.
Something strange though:
I assumed that I was supposed to turn off the ATL, then hold the Reset while powering it on, then I expected in about 15 seconds to see it in the netinstall tool. Something else happened though:
- I turn off the ATL
- I run the netinstall tool:
user@NETINSTALL:~/netinstall > sudo ./netinstall-cli -r -a 192.168.188.1 routeros-7.5-arm64.npk
Version: 7.5(2022-08-30 09:34:59)
Will reset config
connect: Network unreachable
Using server IP: 0.0.0.0
Starting PXE server
Waiting for RouterBOARD...
- I turn on the ATL while holding the Reset for 15 seconds, NetworkManager connects to it and I wait to see it in the console but it does not show up:
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
client: <MAC hidden for privacy reasons>
^C
- So, I interrupt with CTRL+C and assuming that the ATL is already in Etherboot mode, I re-run the netinstall:
user@NETINSTALL:~/netinstall > sudo ./netinstall-cli -r -a 192.168.188.1 routeros-7.5-arm64.npk
Version: 7.5(2022-08-30 09:34:59)
Will reset config
Using server IP: 192.168.188.2
Use Netmask: 255.255.255.0
Starting PXE server
Waiting for RouterBOARD...
client: <MAC hidden for privacy reasons>
Sending image: arm64
sendFile 9046272
Discovered RouterBOARD...
Formatting...
Sending package routeros-7.5-arm64.npk ...
Ready for reboot...
Sent reboot command
user@NETINSTALL:~/netinstall >
- The ATL reboots and I am able to ping it, login to it with factory credentials, I have Internet too.
Questions:
- Did I do everything correctly?
As you notice, I am using version 7.5. The reason for that is something important that I read in the ATL manual today (and which might have saved me all the troubles?):
The device supports RouterOS software version 7.5. The specific factory-installed version number is indicated in the RouterOS menu /system resource. > Other operating systems have not been tested.
So, my second question is:
2. Considering this, should I even attempt to update now (thus potentially risking to end up in a situation when even Netinstall might not be able to help)?
Update:
I still tried to update to see what happens:
[admin@MikroTik] > /system/routerboard/print
routerboard: yes
model: ATLGM
serial-number: <hidden for privacy reasons>
firmware-type: a3700
factory-firmware: 7.8
current-firmware: 7.11.2
upgrade-firmware: 7.5
[admin@MikroTik] > /system/package/update/check-for-updates
channel: stable
installed-version: 7.5
latest-version: 7.12.1
status: New version is available
[admin@MikroTik] > /system/package/update/install
channel: stable
installed-version: 7.5
latest-version: 7.12.1
status: Downloaded 99% (13.3MiB)
Received disconnect from 192.168.188.1 port 22:11: shutdown/reboot
Disconnected from 192.168.188.1 port 22
$ ssh -l admin 192.168.188.1
ssh: connect to host 192.168.188.1 port 22: Network is unreachable
IOW, that brought me back to the state of not being able to connect to ATL. Fortunately, I was able to netinstall 7.5 again and the ATL works again.
New questions arise from that:
- Why does system packages update disconnect and break everything at 99%?
- How come current firmware is 7.11.2 and not 7.5?
- How come factory firmware is newer than 7.5? Does it mean netinstall does not actually touch the firmware?
- Why upgrade firmware is older? What is supposed to happen if one runs /system/routerboard/upgrade? How does one check for and get latest stable firmware? What if that breaks something again?
- What would happen if I netinstall a version newer than 7.5? How to choose the actual version? Is there a risk to break everything in an unrecoverable way (considering the info in the manual)?
This is deeply confusing.
I’d netinstall 7.16, and try that. If there was some security patch, you’d be force to upgrade form 7.5 anyway & have these same troubles (except it could be potentially be back on roof) . If you troubleshoot 7.16 while it NOT on the pole, you’d be better set for future updates.
And, importantly, there are a gazzon updates in LTE from 7.5, so you’d being running to problems with LTE that are likely now fixed.
Mikrotik is not always the best at updating the docs… so someone just forgot to taking out the note about “only testing on 7.5” reference. Since the “factory-firmware” is 7.8, clearly they bump the version in manufacturing. You may have followed the docs advice off a cliff (or roof, I guess).
I’d netinstall 7.16, and try that.
Based on what? The manual is clear - 7.5. What is there to try? I mean - I already tried a regular update… and you see what happens. What is the guarantee that if 7.16 doesn’t work I will be able to netinstall 7.5? Yes, it is possible that the doc is outdated. But it is also possible that it is not. So far, considering the facts, it kind of seems the latter.
If you troubleshoot 7.16 while it NOT on the pole, you’d be better set for future updates.
That’s exactly what I thought too. I do care about security updates. The thing is, I am quite concerned not to end up with a blocked device in unrecoverable mode. With dysfunctional hardware the concept of security is meaningless.
I really wonder how to approach this safely. Support still doesn’t even reply.
Well… a decade of knowing Mikrotik is not great at updating documentation.
And, you have a pretty locked down router, so if you have security needs… there no security patches/hotfixes/etc in older version. Security fixes are applied by going to latest version in the “stable” channel. You’re WAY over reading the docs.
And yes you’d be able to downgrade to 7.5 from 7.16 using netinstall. Or any from/to version, it reformats the “disk”.
You’re really worried about the wrong things if you want this working+stable, and secure. 7.5 is not the way to go. If 7.16 didn’t work, try 7.15.3 first (and report a bug that 7.16 did not work). If you report a problem with 7.5, the first thing support will tell you is to upgrade (and when you point out the docs, they’d likely just delete that part form wiki. Nothing stops you from opening a case at help.mikroitk.com and report your problem with 7.5 & see what they say 
.
Well… a decade of knowing Mikrotik is not great at updating documentation.
I agree. It is not great as a whole but that is off-topic.
And yes you’d be able to downgrade to 7.5 from 7.16 using netinstall. Or any from/to version, it reformats the “disk”.
I understand that it reformats and so on. The question is can some ROS version break that reformat-and-so-on functionality. I don’t see that documented anywhere.
You’re really worried about the wrong things if you want this working+stable, and secure.
Well, that worry is based on current experience. The ATL is not cheap either.
Nothing stops you from opening a case at help.mikroitk.com …
As mentioned, I have already emailed support, which I believe is the same, as I got an autoreply from Jira with a case ID.
/system/resources/print
What is shown as you factory version?
If you don’t believe Ammo: visit https://mikrotik.com/product/atl18#fndtn-downloads Product page, downloads section and there is Router OS package linked.
I would update to 7.16 as well, as long the device is unmounted. In case of a defacto factory configuration I would go even further: netinstall 7.16 with reset. Tabula rasa is sometimes a cure for acting weird devices. And dying after an update is weird and not the regular case. Default configuration may changed as well between 7.5 and 7.16. At least some minor firewall changes I am aware of.
/interface/lte/firmware-upgrade
may be a good idea as well.
Netinstall problems are rare. Well, other than not be able to run it because of OS security block DHCP/TFTP (aka windows), or doing the “reset button dance” incorrectly.
More relevant than “factory-*” version, at least to netinstall, is current-firmware= in /system/routerboard. That is the boot loader (RouterBOOT) and that’s what interacts with netinstall. And so your report about is telling:
/system/routerboard/print
routerboard: yes
model: ATLGM
serial-number: <hidden for privacy reasons>
firmware-type: a3700
factory-firmware: 7.8
current-firmware: 7.11.2
upgrade-firmware: 7.5
So netinstall will actually be working with the 7.11.2 firmware, so that should be fine. But if something/somehow does go wrong with netinstall, and you really brick the router… Which again is very unlikely — that’s when you can likely exchange it with Mikrotik since they do require someone try netinstall before they accept a return.
Where there might be a slighter greater potential for trouble with netinstall is if you’re trying to use a very old 6.x.x firmware/RouterBOOT to go to a recent V& – and even you’d have to go back to a pretty old V6 for that to happen. But V6 was never supported on the ATL, so there is no chance of that happening.
What did the factory version tell you in relation to the rest of the info you kindly provided?
It is not that I don’t believe Ammo - I do. I am just extra careful.
I would update to 7.16 as well, as long the device is unmounted. In case of a defacto factory configuration I would go even further: netinstall 7.16 with reset.
Update (through /system/package/update) is obviously not possible, as I can’t reach 7.16 through sequential step-by-step version updates and reboots. As for netinstall 7.16 - the question remains: Can this break things in a way resulting in impossible netinstall of older version afterwards.
Re. /interface/lte/firmware-upgrade - How does this differ from /system/routerboard/upgrade and should it be run:
- after downloading newer packages but before rebooting
- after downloading newer packages and after rebooting
- any other way?
FWIW, as I am typing this, I am trying download instead of install:
[admin@MikroTik] > /system/package/update/download
channel: stable
installed-version: 7.5
latest-version: 7.12.1
status: Downloaded, please reboot router to upgrade it
[admin@MikroTik] >
I will report right after reboot (or after another netinstall). Fingers crossed.
This has gotten silly. I don’t know what to tell you. You should run latest LTE firmware, RouterBOOT and RouterOS to start and troubleshoot any issues from there.
FWIW… now you’ve likely downgraded the RouterBOOT firmware to 7.5. And if there was somehow fix for netinstall in the firmware between 7.5 and 7.11 - you just opened yourself up to it. I don’t think there is, so likely not problem.
It is extremely hard to actually brick the router so that a netinstall would not work. Could it happen, sure, but that’s a different support case & Mikrotik would likely exchange it if truly bricked from even netinstall. Similar with RouterOS version, while there might be some bug 7.16 (it is new)… your odds are way higher there a lot of bug in 7.5 (that were fixed) that you run into.
Amazing. With “download” it worked! I updated and rebooted. Then I updated the firmware using /system/routerboard/upgrade.
Now I am getting:
[admin@MikroTik] > /system/package/update/check-for-updates
channel: stable
installed-version: 7.12.1
latest-version: 7.16
status: New version is available
[admin@MikroTik] > /system/package/update/download
channel: stable
installed-version: 7.12.1
latest-version: 7.16
status: Downloaded, please reboot router to upgrade it
Rebooted successfully, upgraded firmware to 7.16 too, rebooted again and everything works:
[admin@MikroTik] > /system/routerboard/print
routerboard: yes
model: ATLGM
serial-number: ...
firmware-type: a3700
factory-firmware: 7.8
current-firmware: 7.16
upgrade-firmware: 7.16
[admin@MikroTik] > /system/package/update/check-for-updates
channel: stable
installed-version: 7.16
latest-version: 7.16
status: System is already up to date
I don’t know what to say. Of course I thank everyone for your time!
The question is - is “download” vs “install” the key to safe updates? What did “install” do at 99% which “download” did not? Besides that, I have no explanation.
You insisted to use ROS 7.5. If your factory version would have been already a newer version, like e g. 7.6, then you wouldn’t even be able to install 7.5. You can’t downgrade below factory version.
Interesting is: your factory routerboard firmware is 7.8 but your factory ROS version is 7.4.6. don’t know how this is even possible
And finally don’t forget /system/routerboard/upgrade
Good news. Sorry if I sounded short, but 7.5 was just a bad idea. And totally get it was some Mikrotik that who somehow broke it, to require the roof + netinstall. And, clearly MT should remove that “7.5” reference (or update the page so highlight that someone re-confirmed it ) to avoid this problem in future. Since the docs are ~95+% right, someone might actually believe that part is also right .
Download does just that. It download the package files to the flash, but does not install them. The way packages work is if any are in the root file system when you reboot, they get applied. So you can download them yourself from mikrotik.com, and put the in the root to also upgrade a router. So the “download” essentially just automates that for the channel (i.e. “stable”).
The install does the download, and also triggers the install, by rebooting. But as soon as it finish downloading, it also reboots the router to use same .NPK files in root. Since that reboot happens immediately after download, the 99% may show because it started the reboot before the UI update made it to you.
Finally, If LTE is working, you might have done enough upgrades for one day. But it might be worth it to upgrade the LTE modem firmware too. https://help.mikrotik.com/docs/display/ROS/LTE#LTE-Modemfirmwareupgrade - which ironically has the note:
Before attempting an LTE modem firmware upgrade - upgrade RouterOS version to the latest releases > How To Upgrade RouterOS
… and the HOWTO upgrade link explain how packages work.
Basically the docs are reference manual, not a guide. So the information need to just setup is spread across a lot of pages.