Device-mode changes hit or miss? Mikrotik strategy?

RouterOS General
1

Not even sure how to approacv writing this post, but I decided not to swear and not to be sarcastic.

After hitting the issue where router dissalowed me to set silent boot, I spent some 15 minutes to read and try to understand the 7 minute read on:
https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode
and try to figure out if I am reading an April’s fools joke or this is for real?

I believe this is completely wrong decision and implementation, for the following reasons:

  • I use Mikrotik because it has tons of features available, so limiting them seems couters original idea why we love it.
  • I already have tons of Mikrotiks in production that use most of the features that now suddenly became disabled in management part with the latest firmware upgrades.
  • I need to go and visit tons of Mikrotik to power off/on manually or press button to restore the original functionality.
  • I need to list the mode and every feature I want changed, otherwise features are disabled by default when setting the mode alone.
  • I need to do this excercise for all new routers, which is a pain, but is something I could live with going forward.
  • If I need to do this excercise for all implemented routers and on all sites, this is close to impossible.
  • Even if doable, this is certainly something I don’t want to do and I am not sure if Mikrotik will reimburse me for something like?
  • Considering new update automatically disabled features, without asking to confirm, nor explaining this in detail in changelogs?
  • How should future feature additions be treated? Will I need to run arround and reboot routers to turn on the new firmware features?
  • This got me worried, as normally I accept to work only with equipment and manufacturers that don’t bother me, conceptually at least… So I hope this is something that will be re-considered internally and addressed properly.

To explain in details, I avoid all corporate crappy vendors and their equipment due to:

  • unpublished priced and vague equipment pricing by resellers and partners, division between their tech & sales staff making purchase pain
  • feature selection vs cost of each is painful to familiarize with, as not clearly published
  • complicated correlated licence models, configuration management and upgrade paths
  • short device EOLs (in reality anything less than 10 years shouldn’t be allowed to hit the market legally in the first place)
  • multiple levels of support staff until I reach someone knowledgeable
  • marketing has decision priority over tech
  • broken OS CLI standardization accross devices and inconsistencies that prevent easy automation
  • pain with keeping support subscriptions and required inventory associated with that
  • automated features that don’t work but don’t allow admin settings
  • not maintaining downward compatibility
  • different set of features accross markets/series/models,
  • region locks for WiFi and similar (impacting transport industry),
  • general lack of even the most basic of features
  • bugs and lacks due to minimum feature set orientation and time to market which I need to cope with and depend on vendor to fix also breaking
    other features
  • knowledge base and firmware updates (even security) conditioned by support subscriptions, together with device inventory contract maintenance and other administration required to support that
  • proprietary protocols standards and efforts for vendor lock-in
  • bloated software distributions, bad developers, often scaling issues, and overprovisioned hardware requirements

Please understand I try to avoid such mess and found Mikrotik to counter all of the above over years, but it took me a while to adjust mindset from Open Source to Mikrotik Proprietary, which generally doesn’t have all the above listed downsides.

Yes, it is not perfect with only offering limited email support etc. delays in implementation of latest features over SOHO market, but the product consistency, bug and other issue aviodance should counter this, together with ability to automate around any issues or freely rollback versions when issues do occur.

But most important is to assure stable releases, downward compatibility and that users/admins are not pushed into anything willingly or otherwise.

So I would propose Mikrotik to form some Quality control Department on this, but not the typical one… that only hadnles the product development cycles, but the one handling the company strategy having customer’s efforts, cost, administration and all other pain in using Mikrotik devices to a minimum.
I know easier said than done, but as Mikrotik grows bigger and number of functionalities/models increases, keeping all this aligned is a necessity.

Now regardless of issues with device-mode I will survive, but wanted to write this for what is worth, hoping someone in Mikrotik will understand where I am coming from with all this.

2 Likes
Device-Mode Enabled on Majority of Newly Received Routers – Causing Major Deployment Delays
2

If your complaining about you run your support business, wont get much sympathy from here.
There are tools within RoS to accomplish much and if not so technically astute sign up for something like this… https://admiralplatform.com/

3

I’m like you… features works before and can be easily enabled/disabled without any problem.
Since 7.16 or 17, don’t remember, i have the same situation, just to change de cpu speed, i need to visit all the country for do that.

4

You can still downgrade to 7.16, change the cpu speed accordingly, upgrade to 7.17+ again. Problem solved.

5

Consider yourself lucky. France is not so big. Imagine @anav visiting e.g. Whitehorse suburbs to change cpu speed :wink:

6

Maybe you can name these features and use-case you have/had which are now not possible anymore after 7.17 device-mode changes. Mikrotik needs some real-world examples.

7

Yes, i’ll wast time to play between with downgrade, change and re-upgrade… that a good idea.
I want to reduce my parts count… on edge router, because not possible now too.

8

Nothing a trained cat cannot salvage.
Just hire mkx :wink:
…
mkxyes.jpg

9

Although with device mode some input from the community was taken into account, it was not nearly enough. Originally device-mode limited some things. Okay, most of these were newly introduced anyway, like containers. Then device mode limited more things after an upgrade. Okay, we have to reset/unplug everything. When will the next device mode limitation happen? Every 6 months from now on? Yearly? Mikrotik’s routers could previously operate for 10+ years with no one going near them. Maybe doing this once is acceptable, but having this become part of keeping a device updated seriously messes with many people’s workflow. (Okay, increasing the market for trained cats is maybe an overall positive.)

Why can’t there be an “I don’t want further restrictions” device mode? (Maybe a special package to signal this admin intent?) Why can’t there a “special” upgrade mode that doesn’t disable things? (The device-mode stuff is stored in the bootloader section along with the boot order, etc., so even if there was such an upgrade mode, that wouldn’t mean that someone could downgrade then use this mode to get around restrictions…)

And finally, some models (such as the rb5009, one of my favorite products in the lineup) are severely gimped if the cpu frequency cannot be set. Why lock this behind device-mode?

I understand that Mikrotik sometimes has a habit of introducing stuff with an “introduce it then fix it later (whenever)” process. For new features this is not a bad thing, because people can experiment with it, report bugs, etc. For a feature that actually locks away functionality however this is not appropriate.

10

Your choice: travel France or press button or downgrade/upgrade.

11

Please stick to the facts. Under the old “enterprise” device mode, everything was allowed - except containers. Not “limited some things”.

I therefore quote from the docs page history:

By default, all devices use the mode enterprise, which allows all functionality except container

Now there is the “advanced” mode, which adds: traffic-gen, install-any-version, partitions & routerboard

12

100% agree. The whole device-mode stuff is just sloppy engineering, and some “physical presence” was something I never considered when placing remote units.

It was already annoying with “container” device-mode, since you cannot then use netinstall+config to add container(s) as part of some automated provisioning. It would have been 10x better if I could remove some package, or a “real” policy system, if goal was to reduce attack surfaces. As noted many times, I might want to remove MORE features to reduce my own security risks (i.e. I actually don’t want a hAP/wAP/“home” thing to enable features that could mess with upstream networks). Instead we got sloppy half-way house of device-mode, that is just PURE DOWNSIDE for my use cases.

13

Thanks for the correction. It originally only limited container functionality that was newly introduced. It would read correctly as:

Originally device-mode limited one thing. Okay, this was newly introduced anyway, namely containers. Then device mode limited more things after an upgrade. Okay, we have to reset/unplug everything.

The rest is correct. As per the changelog:

What’s new in 7.17 (2025-Jan-16 10:19):

!) device-mode - after upgrade, mode “enterprise” is renamed to “advanced” and traffic-gen, partition (command “repartition”), routerboard and install-any-version features will be disabled;

So features were in fact disabled.

The Mikrotik confluence page on the subject is clear in one respect:

There are three device modes available for configuration (mode=advanced is default one), each mode has a subset of features that are not allowed when it is used. Note that > there is no mode, which has all features enabled.

(emphasis in original)

There is no mention of if or when a new restriction will be imposed. The above quote hints that it may be at any time. And my first quote indicates that when it arrives there is no plan to make it avoidable while still keeping the device up to date. This is my main complaint.

14

I don’t think the docs are that relevant to core concern.

device-mode should at lease be controllable – via some tool like netinstall or some “special package” or whatever.

15

This means, when doing netinstall and a custom script, the device mode restrictions still apply? So one cant setup a device from scratch and disable all device-mode flags by scripting? If yes, this would be bad.

16

I agree with most of the complaints about the implementation and how this has been handled; the device-mode restrictions are very annoying to have to deal with, especially when it is a remote device that you have upgraded and that you previously had full control of prior to the upgrade.

That said, it does seem pretty clear to me that these new default restrictions are pretty much being made by MikroTik with security in mind, not with the goal of taking away user’s freedoms. For example, with the new containers feature, they didn’t want a device to get compromised remotely and then loaded up by a bad actor with an app in a container that made the hacked router even more of an annoyance on the internet than it would be otherwise…giving a router the feature of being able to execute arbitrary code is an extremely powerful feature that, in the wrong hands, can lead to bad consequences. Furthermore, restricting remote downgrades to specific versions is obviously being done because without it, somebody who compromised a router could downgrade back to any version that does not enforce these restrictions, rendering the restrictions completely pointless as a security measure. Finally, that you have to be in the physical presence of the router to unlock any of these features is obviously just a way to prove/authenticate that you indeed are the owner of the router in question, and that you are making an intentional choice to enable potentially dangerous features.

Where this falls flat is that, as long as you can still downgrade back to any 6.49.x version even with install-any-version=no, the downgrade restrictions are completely pointless and just increase the number of steps necessary that a remote attacker needs to take in order to get the router to run the exact pre-restriction version of ROS that they want. For example, if they break into a router running 7.18 and want to run 7.12 instead for whatever reason (maybe to work around other device-mode restrictions), once they manage to break into the router, they just downgrade to 6.49, then back up to 7.12. So all that MT has done is to make things more annoying for legitimate users, by merely inconveniencing bad actors.

I think an apt metaphor would be copy protection. Except that MT’s goals here are at least somewhat laudable, while mechanistically-enforced copy protection is just misguided (understatement).

It would probably be better if a strategy more along the lines of the following were guiding MT:

  1. Existing devices – especially those that originally shipped with 6.x – should just get grandfathered in, and no device-mode restrictions enabled after upgrade to 7.x unless the user agrees to them first. I would even be okay with RouterOS prompting the user after the upgrade, similar to how RouterOS will hound you to set an admin password every time you login if it is blank. Except that if you answer “NO”, then it needs to honor that and not ask again.

  2. Devices that ship from this point forward have a sane set of device-mode default restrictions that are set from the factory, but which can be overridden in person, just as they can right now (by pulling power or hitting Reset within 5 min. of the request).

  3. There does need to be some way for device owners to be able to set or unset device-mode restrictions in bulk, such as with using Netinstall. The tricky part about this is of course that you don’t want an attacker to be able to remotely configure a compromised device to netboot in order to work around this; however, that’s what the routerboard device-mode restriction should prevent.

17

@infabo: There is currently no way to set device-mode in netinstall scripts (without the unplug/reset procedure) It was suggested by many to allow only scripts executed as post netinstall scripts to be allowed to do this. As far as I know, it was not implemented.

The device-mode settings persist independent of netinstalls. I think they are stored together with other routerboard level configuation.

@NathanA: The goals of device-mode are indeed admirable. While you have the device on the your desk for preconfiguring it, of course you can disable as much of them as you would like. (It would save time and simplify things if it could be done in a netinstall script, but that’s something I can live with.)

My concern is that there will come another media storm, where Mikrotik routers are singled out for being parts of some botnet, and (also in the name of security and with good intentions) another set of features will be restricted by a new device mode. Then at least some people in some situations will wind up in a situation where they have to either defer any possible updates (maybe indefinitely,) or live with the new restrictions. If this was not really thought through for 7.17, will more consideration be given to it when this comes up next? I hope so.

18

Didn’t even notice all the updates since posting this yesterday, so I edited the original post after the fact, apologies.
I tried to extend my bitching in the original post to something more substantial for the future like Mikrotik’s strategy.
As this would impact all features created in the future where I really don’t want to critisize, but instead praise Mikrotik.

Limiting features to reduce the attack surfaces is fine, but is a tradeoff from where proper code, updates and passwords should prevent these issues in the first place.
Either way, having another safety net is not bad by default. After all if you don’t need some features, why keep them available for missuse?
Also anothe idea would be to have these features as packages so to choose to install them or not like done since ever.

Rollback to prior version is OK, but is not really a solution.
Having a simple note “This upgrade will do this and that, so are you sure?” prompt would have been a solution to this problem.
But I believe the issue is bit more generic in nature than that.

In essence, I believe I am not far off when stating that admins want to be undisputed “gods” within their system relms.
Dirigents that orchestrate and control the environment, like a well played-in orchestra, where each system behaves like a professional player.
This means each device is lean and mean machine that works deterministically, without bloat having highest performance achiveable.
And this shoould extend to the entire company, with all products and their lifecycles and be consistent throgh the years.
Any company messing with that one way or the other will suffer consequences, with many excelent examples all over.

So just wanted to note this as a guiding star for any decisions.

And having said that, I cannot avoid mentioning new Winbox as a perfect example of what I am trying to convey hre… which is sill miles behind the old one and I’m not sure if it will ever catch.

19

I hope so, too. As I said, devices that existed prior to device-mode being a thing in my opinion should be grandfathered into some mode similar to the “enterprise” one that they deprecated, rather than have the new restrictions be placed on them upon upgrading to the latest and greatest software. Call it “legacy”. Or, heck, bring back “enterprise”; I don’t care and the name doesn’t really matter.

Perhaps this concept really should be extended to any new restrictions that they dream up and which they decide to have imposed by default on new devices. So if a device shipped with 7.17, then it would have the 7.17 restrictions, but devices prior to that which are upgraded to 7.17 would not by default. If hypothetically 7.19 introduces even more restrictions, then devices that shipped with 7.17 or 7.18 should also not have them imposed on them upon upgrading to 7.19, even if the 7.17 restrictions were being imposed on the same device.

20

Correct… something like that would be better.
But please note admins should be able to opt-out from any newly imposed restrictions during an upgrade process, so not to have to go & power off/on remote devices to re-enable features after an upgrade or do any other tricks…

When it comes to security, why not implement 2FA with OTP code?
And why not implement extending time delay for incorret auth attempts?