My complaint is NOT about routerboot settings!!!
My complaint is about new device-mode settings that disable existing features that can only be re-established with physical access.
In particular: routerboot settings, active partition changes, and downgrade to a manually uploaded version.
(the latter mainly because there is no previous-stable channel, as others brought up already)
that you can’t switch to “try-ethernet-once-then-nand”. You can, switch now and upgrade later.
You may not know that setting bootloader to “try-ethernet-once-then-nand” does not stick, it only remains active until the
next reboot. What I would like to see is a “try-ethernet-for-30-seconds-then-nand” mode that does stick and that we can set
in locations where we would like to be able to netinstall some time way in the future, e.g. tower installs of access points.
But that is a different matter, let’s not confuse the current issue.
about partitions, their purpose is to reboot into backup, when device fails to boot. this works without any device mode changes or settings. if you have such a setup, nothing has to be done after upgrade. you can create partitions, copy active partition to backup partition etc. and it will fallback to backup, if device fails. no button press necessary.
But you do not cover the situation where we have version X in active partition, version X-1 in backup partition, it has been
running and reconfigured for some time and then the power is cycled a couple of times (sometimes happens here when e.g.
internet is down and people unplug the equipment, wait one minute, unplug again because it still doesn’t work).
Now the active partition is the old version, which may run but we want to get back to the version X so need to switch active
partition and reboot.
Happened in the company earlier this week (triggered by a strange bug in 7.16 that I still have to further investigate).
What we all can agree on, and I hope even normis agrees on it: the “grace period” is way too short. It is not like this device-mode changes happen in 2026 and several precautions can be taken. No, it is - at least planned - to happen in next upcoming “major” release.
Yes, that is also why I suggested that the device-mode settings are made available earlier than that they are enforced.
But Normis plays stupid and pretends he does not understand…
Yes, that is also why I suggested that the device-mode settings are made available earlier than that they are enforced.
Not really. It does not matter if it is now or later version, but the new device mode should not force you to go and physically visit all running devices.
I already explained, that if you have access to this device and are able to issue commands, you can also fix your config in other ways, not just by partition change. And if a script can do things in your router, so could an attacker. Those people that have thousands of routers that all use partitions and automated upgrades, that switch to backup partitions, when something can’t be pinged (netwatch), yes, will have to manually enable partition mode for this to be possible. But I personally think there are better ways to protect a device against failed upgrades.
The major problem I forsee ahead is the fact, that - I have no evidence - only 3/10 people read changelogs.
So this little line
!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
will not get the attention. And once you’re on 7.17 and find out the “hard way” that you’re device just received some device-mode “lockdown” is to be the next #1 topic headline in 2025 Mikrotik forum.
It is like with 7.13. People netinstall e.g. 7.16 and wonder where there wireless interfaces have gone. Yeah, because they did not went the advised upgrade path (first to 7.12.2, then 7.13+) or when doing netinstall did not read the changelog to just find out, they now have to install one additional package aside main package to have wireless working.
Just saying, this will introduce a tremendous amount of support tickets and even more controverse feedback in the 7.17 stable release topic.
But you need to have physical access to the device!!! For new devices this is OK and everyone will count with it.
But for already deployed devices in production it is a PROBLEM.
You force people with thousands of devices to visit it physically and make a change or give up on functionality.
It starts to look like some at Mikrotik are not exactly familiar with the concept of managing devices in inaccessible locations or located in other country (or even continent)…
Also, a home user doesn’t need BGP, MPLS, OSPF, RIP, or 99% of the functionality of ROS. What a home user needs is one big button — “Make everything work.” I appreciate your concern for home users, but how about releasing a separate firmware for them and not touching the professional devices?
I think you don’t understand (just like you pretend to not understand ANYTHING in this matter) what a grace period would be.
A useful grace period would be some time where we can PREPARE for an upcoming change in a non-disruptive manner.
E.g. when 7.16 would allow to set the new device-modes, we could set them when the opportunity arises, within that grace period.
It is not “7.17 will be released in 4 months time so you have 4 months grace period” because after those 4 months, we still have the situation
where an upgrade immediately kills functionality.
It looks like someone at MikroTik, maybe as part of a security meeting, has decided that there is a real risk that someone would obtain admin
access to a device and then would want to have even more capabilities and would achieve that by downgrading RouterOS.
While that undoubtedly has happened somewhere, I wonder how realistic that is as a major threat to the millions of deployed routers.
For one, there is always a minimal version (factory version) and it increases all the time. One batch of RB5009 we bought has factory software 7.5,
another bought 2 months later already has 7.8. So downgrade below that isn’t possible at all.
Then, the whole issue of “downgrade would make devices vulnerable” is only a valid concern when devices are in fact UPGRADED by their users.
I think a much more effective measure when you want to improve security and want to avoid exploits by devices running lower versions is by
implementing a mechanism for auto-upgrade!
I know that it is possible to implement it using scripting, but only some very interested (or experimenting) user would ever do that.
Most experienced admins would want to keep things under their own control (especially with MikroTik sometimes going haywire like now), and
the casual home user has no expertise to get an auto-upgrade script configuered.
When you really are worried about device security, a much more effective step in 7.17 will be to implement an auto-upgrade as part of the
default configuration, which e.g. checks once a week at a nightly hour of there is a new version in some channel, download it, and either present
a popup in the config tools that tells the user “update available, reboot to install” or installs it automatically after another couple of days.
Then at least you have some way of assuring that naive home users keep a reasonably uptodate version, so there is a “need to downgrade”
for the attacker in the first place!
It would be best if there is a separate channel for this, which gets updated only when there are fixed vulnerabilities, not just for the sake of
having new features. To limit the risk of bricking devices for no reason.
Your competitors already have this. They have some config selection “auto upgrade firmware”, enabled by default, that the user can turn off
if they wish. You can have the same thing, just by having some scheduled script that can be disabled from QuickSet if desired.
Another improvement would be a feature to “upgrade settings on routers running defaults”. E.g. to upgrade the firewall config to the new
default, or to add the abovementioned scheduled script. As it is now, no improvements in default settings ever get implemented on routers
that already have passed their first powerup. That could be improved to have better security.
To be honest, the most surprising thing coming from this topic is that people use partitions, even though most of our devices don’t have enough space for that.
This feedback will help us. What would be much better if you could describe actual use cases, like @bmann has done, instead of “nobody understands how people manage devices”. That is not helpful.
We don’t buy the toys that have only 16MB for business! And I (and others) have argued a lot against them.
When I first bought MikroTik stuff it was devices like the RB2011 and I immediately partitioned it.
Only later things have gone downhill with all those 16MB devices and the issues they caused (at home, mostly).
Also, please stop projecting your own view on the world onto others. When we say we require functions, you can
believe it without us writing a dissertation about it. Which you probably will only glance over anyway.
Except when config is internally f*cked up by an upgrade and manually fixing the issue is no longer possible. The only solutions in this case is either switching to a still working partition or doing netinstall.
Also using switch channel to downgrade from a “stable” release is not possible, as long-term does not exist in the v7 train (yet).
This won’t work with the options that did not exist before 7.17.
Maybe, release a version where partition, downgrade and bootloader are known, but have no effect and can be updated remotely, let people who need these features on a remote devices update them, and then start enforcing them in the next major release?
andriys let me repeat the question. you have full access to the router. what could be so f***ed up that you can’t fix it from the fully working command line, but you can type “partition activate” command?