Are you not aware of how auto-upgrade=yes works? It IS sequential by design from Tik. First you update ROS, then it injects the firmware into memory, then you reboot and then only the firmware gets flashed.
It is NEVER not sequential.
(@DarkNate don’t use that rude language)
RouterBOOT / BIOS and RouterOS / the System is like a BIOS on motherboard and Windows (Linux, UNIX, etc.)
This difference has always existed and it is perfectly normal.
When I update an RB, I first extract the .fwf of the appropriate chipset from the .npk file inside the “etc” folder.
Next I put both the .fwf file and the .npk file in the root folder of the RouterBOARD, then I update with “/system routerboard”, then reboot.
Done, just one step.
The point is: why doesn’t RouterOS do it directly when auto update is yes, instead of waiting for reboot, to reboot later?..
Not sure what rude language – But the difference isn't clear with Tik as others pointed out. I've never bricked motherboards when flashing UEFI in 15+ years, but come to Tik land and all hell breaks loose.
Note: BIOS is dead since 2013, all modern mobos do not have it, it is only UEFI with some legacy support for BIOS in some models.
The point is simple: Poor Q/A from Tik as always… Arrogant too.
Oooooohhhh call it BIOS, call it RouterBOOT, call it EFI or UEFI, still a Basic Input/Output System than load, after some initializations, the Operative System…
Also SSD and other devices have inside own “BIOS” / firmware, etc.
BIOS / UEFI are not the same underlying code/logic on motherboards. It's not just a marketing term brought up by Microsoft.
Though “firmware” applies to SSDs/GPUs etc, some calls them "BIOS" and makes perfect sense, UEFI is motherboard specific.
Either way love or hate it, Tik isn't fixing the real problems.
Is why some punctualizations are perfectly useless.
The irony is that Google forces a somewhat low security password - it is 16 characters, but all lower case - no upper case, no numbers, no punctuation.
That’s plenty even for a massively parallel offline attack scenario.
MT telles that there are no (rarely any) changes, so no need to upgrade to save time while upgrading.
The problem is that it does not work at all in scenarios where the stored password is leaked. E.g. someone puts it in their RouterOS config and posts a /export show-sensitive somewhere by mistake, or there is some bug in some device (can be anything, not just a MikroTik router) that allows reading this stored password.
That is what 2nd factor authentication solves, however it is not usable for such things as a router sending alerts by mail.
The question is, how to solve that. One way would be not to use mail for such things. Or at least do not use your main account, use a throwaway account only for this purpose.
Indeed one should never have some scripted daily auto-upgrade tied to the “stable” channel! it was again demonstrated that a new version that had 2 release candidates in “testing” is suddenly promoted to “stable” with known issues and even some last-minute changes. That is just not a good thing to do, a “stable” version should have been a release candidate at least for some time to get reports like this, and then it should just be promoted with no changes whatsoever. When there are changes, first make a new release candidate.
Now MikroTik argues that for this auto-upgrade one could use “long-term”. However, the release policy of long-term is exactly the same: there are long-term versions that are not copies of the last stable, but have some additional quick fixes that could result in the same situation.
So ideally when you run an auto-upgrade script is should only trigger after the posted version is at least some days old (like 14 days or so), but that is probably difficult to do.
In the days when firwmare had version numbers like 3.1 the firmware had separate version numbers that were incremented when a change was made. After updating RouterOS and going to the System Routerboard menu you would SEE if there was a firmware newer than the one on the routerboard and you updated it.
But at some point, the firmware version was made the same as the RouterOS version and now you get an update every time, even when nothing was changed (other than the firmware version number).
That has not made the situation clearer. Now you need to do an extra upgrade and reboot every time, and the system does not support automation of that.
E.g.:
- when you set the automatic upgrade in /system routerboard, and it has performed the update, reboot immediately
- or: perform the firmware upgrade as part of the routeros upgrade, which is in fact done by the running versionjust before the reboot, so the firmware upgrade could be part of that and the reboot required as part of the routeros upgrade also activates the new firmware
Okay, so here’s what I did to fix the bootloop created by our amazing crap Quality Assurance experts and good ol’ arrogant Tik inc.
For RB3011, you don’t need to remove SFP module:
Remove fibre, it will boot, login, downgrade to 7.2.3 and do the same for firmware, reboot again.
For those using PPPoE:
Disconnect Ethernet cable from WAN ports on which PPPoE client is running, it will boot, login, downgrade to 7.2.3 and do the same for firmware, reboot again.
Once I have the budget, I’m leaving Tik for good and encouraging all my peers to dump CrapTik on both L3 and L2 – Hearing good things about Huawei, Arista and even DANOS.
You’re expecting too much from CrapTik experts. They can’t even ensure long-term is “long-term” as others pointed out in this thread and other discussions for the last 5 years.
It’s 2022 and we don’t even have dynamic ARP inspection on Tiks.
Solution: Migrate to a different vendor once your budget permits.
Exactly why I have several gmail accounts for only that purpose (or for one-time registrations) next to my regular one … already for a decade (at least).
You could also use Telegram, Twitter, whatever … it will all become the same problem.
With O365 there is an option of trusted subnet to skip 2FA. If you got a fixed IP that’s also a workaround if you want to use that service.
But for mobile setups or dynamic IP allocation, that will not work either.
There will always be a situation where 2FA is simply not possible.
As far as I have tested, this authentication using APP password has limited use. You can not logg inn to an gmail account with it (using web), so you can not change anything.
But to be safe, create a new gmail account, its free. Then forward stuff you send to that email to your normal email.
As far as I have tested, this authentication using APP password has limited use. You can not logg inn to an gmail account with it (using web), so you can not change anything.
There are (IMHO perfect legitimate) reasons for APP passwords:
- If it leaks, you just can revoke the APP password using your main login without having to change your main or any of the other APP passwords.
- A leaked APP password can only be used for what you allowed when creating it (accessing eMails and/or Calendar and/or gDrive and/or etc.). It never can be used to login to your main Account and most important not to change things or change any PWs or creating additional APP PWs or access CCs for the Appstore etc.
So it might be a bit inconvenient in some cases, but it’s for sure much safer than using your main Google PW in routers and similar exposed devices.
Yes, it makes some sense. Of course it is better to have such a limited password than your full account password in the router.
I only wanted to indicate that Microsoft is ending the support for APP passwords in O365 soon and allow only “modern authentication” (meaning 2FA), and so it would not be unexpected when Google eventually does the same thing.
I don’t know how they think that unattended devices should continue operating under that regime. It affects IMAP as well, e.g. we are polling some O365 mailboxes using “fetchmail” and it will not be possible anymore.