Brian, from all the issues raised, I wanted to clarify one point. You wrote that you would have loved to provide your input, but I see from the support tickets, that my colleague did ask you some questions about this Device Mode in ticket SUP-178031, but we never received any replies from you. I do not like to ask this in a public forum, but since we have no replies, maybe our emails are not reaching you. Of course this was a year ago.
My approach is similar, my branding defconf script is ~2500 lines of script, with much of that being highly optimized because it’s loading local and global functions that vary from a few to several hundreds of lines long each. Just my wifi gobal script (the one that creates the global functions that are called by the other scripts and functions to control wifi interfaces) is over 1k lines long by itself.. All of this I’m loading on the router via the branding maker, and it’s getting revised and updated for each and every build of ROS that I chose to deploy. This same branding package loaded with scripts also runs on wifi5 wireless devices as well as wifi6 wifi-qcom devices, and the scripts do device version and package detection and adjusts the configuration based on the device it’s being installed on, and even the hardware options.
When you have that complicated scripts it must be very difficult to make them version-independent…
I already had difficulties when generating a BGP configuration that can be cut/pasted into a router, because command line commands/parameters are changed (2 times in 7.20.x) and although it converts existing configurations when upgrading, it does not accept old-style configurations in new versions.
Normis, Thanks for the follow‑up. Since this is a public thread, I want to clarify the record for everyone reading, and so I’ve shared the entire conversation with support in the attachment. Warning, it’s 9 pages of almost entirely my replies and input on the matter at hand.
However one fun one that I’ll include is this snippet of the reply dated Feb 11 2025, but instead of responding to the core problem, your staff chose to question why I wanted to change a setting instead of address the core problem. So who is the one that’s not receiving replies? It sure as hell isn’t you!
Beyond the direct operational impact, MikroTik's compliance with the Cyber Resilience Act (CRA) is likely in violation. The CRA (link) mandates that manufacturers must ensure customers can apply necessary security updates. Your current approach—automatically enabling device mode upon update, which is breaking existing functionality without a remote resolution—directly violates this requirement. You should be aware that non-compliance with the CRA carries potential fines of up to €15 million or 2.5% of MikroTik’s total worldwide annual turnover, whichever is higher.
…
I need a clear response on how MikroTik intends to address this issue. If there is no road map for quick resolution, I will be forced to take action to protect both the security and financial investment in our fleet of several thousand currently installed and in use MikroTik devices.
I expect a prompt response and prefer that response to come from senior-level management on this matter. Be advised that failure to respond adequately or commit to a resolution will force me to escalate this through all other channels available to me.
But back your question about providing my input, The original ticket from 31 Jan 2025 did raise these exact concerns, the operational impact of Device Mode on deployed devices, the risks of automatic application during upgrades, and the lack of any remotely manageable mechanism for large‑scale fleets. Those were the core issues I brought to support a year ago, and plenty of others have too.
The responses I received at the time did not address those concerns. Instead, the conversation was redirected toward explaining how Device Mode works today and how to configure it on new devices, which was never the true core problem. The true core issue has always been what happens to existing, remotely deployed fleets and the fact that physical access is impossible in many operational models.
That’s why the ticket stalled: the question being asked was about why I was fixing the CPU frequency settings in my script that you failed to update correctly on the v6 to v7 upgrade, and entirely orthogonal to the actual problem. Answering that question would not have moved the discussion forward. This isn’t a matter of missed emails, it’s a matter of the core problem not being acknowledged or engaged with, or outright ignored by MikroTik for over a year.
Since then, nothing has changed on the Device Mode front, and more operators have raised the same concerns across the forum. The position I’ve already stated privately and publicly still stands, and everyone here is aware of it. Collectively yes we have figured out how to deal with the device-mode from the factory problem, it has cost us all a lot of time and aggravation to deal with, and continues to do so so long as nothing changes, but it’s at least possible to deal with. The existing and deployed devices are the true problem which you have refused to engage your customers on, because that problem is impossible for us to deal with, there is no work-around for us to deal with (unless maybe rextended is onto something with the CPU / watchdog crash thing), this is something you must fix.
I’m absolutely willing to provide detailed input, but only if the discussion is centered on the real issue:
We need a secure, supported, remotely configurable Device Mode model that does not break existing deployments or require physical access.
That’s the conversation I’ve been trying to have for the past year, and I’m ready to continue it, as long as we’re addressing the actual problem, not procedural footnotes about why I might want to change a setting, lets keep the conversation focused on why are you requiring physical access to toggle a control before allowing me to change that setting.
The full content original support ticket being referenced by Normis, dated just shy of exactly 1 year ago is attached, with my contact information redacted. If anyone wants to read the full conversation to understand why I gave up on answering, feel free to read the whole conversation, you’ll see they were ignoring the real problem.
edited to fix a typo, and to say @normis I prefer my eggs sunny side up, but when you’re done scraping the egg off your face, I’ll take an omelet.
SUP-178031_DeviceMode_Conversation.pdf (17.3 KB)
I’ve run into a few routers and radios I’ve upgraded and, for whatever reason, the CPU setting was not the default (or not migrated to “auto”). With device-mode now locking that out, I’ll forever get the alarm that it’s not at defaults, and remotely, I can’t change it for those routers without 1) calling the customer, 2) enabling the feature, and 3) having the customer power-cycle (or reset or whatever else).
The underlying trend in these discussions is MikroTik devs appear to only be thinking about 1:1 or 1:10 relationships (1 human to 1-10 devices), which is a large portion of their deployed base. But we ISPs and MSPs feel like they’re not thinking about the portion of their base that has 1:100-1:1000 deployment ratios.
The messaging, at least, leaves the impression that scalability isn’t important (or has to take a back seat to security). I’d like to think it’s just because they haven’t cracked that nut yet, and are erring on the side of caution due to the legal reasons mentioned earlier.
In my opinion the #1 issue that MikroTik has with product planning, like that surrounding Device Mode or the AX series
design in general, is that you spend too much time listening to small but vocal home users and hobbyists
None of the hobbyists asked for a device mode.
FWIW, I’m operating closer to the 1:10000 ratio, so these issues are magnified even more so for me.
Agreed, but the critique (at least in my head) was intended towards things like rose storage, smb, wireguard, back to home, etc. Version after Version coming out with new SoHo features, while enterprise and ISP customers were screaming that we really don’t care about those things, especially so when existing features aren’t working correctly, just make the core system better, and ideally keep all those SoHo type of features separate from the core OS bundle. In fact a SoHo package that is optional and includes wireguard, media, kid control, and quickset would be awesome, available to those that want it, not for those that don’t. I wouldn’t even mind if installing the SoHo package auto-enabled device-mode, as long as it was left off by default for the rest of devices, and remotely manageable.
... and they are very effective influencers, that's why we have the USB port on the Ax 2 ... 
Also, in many release topics, users explicitly asked MikroTik to remove SMB from RouterOS packages. Instead, MikroTik added features such as DLNA, Adlist, and ROSE, none of which were requested by hobbyists. In the case of ROSE, many professionals commented in the forums asking MikroTik to focus on core routing functionality.
MikroTik also introduced BTH, which again was not requested by hobbyists.
It is clear that MikroTik follows its own agenda and roadmap. I agree that the focus has shifted more towards SOHO features, but not because of pressure from "influencer hobbyists". At least I think that is not the case.
But who doesn’t need to charge their cell phone from their home router, right?
Seriously though, I’m not complaining about the presence of a USB port. There are some edge use cases that it can be used for, but in reality for the same price I would MUCH rather have standard 802.3af/at PoE power input on the AX2 than a USB port. Both of those features cost money to include, but only one of them helps me sell more routers. If people really want a USB variant to run a container on their AX2 router, then maybe sell a version with more RAM and a USB port for those people. I’m willing to bet it wouldn’t sell enough to justify the production run, yet 802.3af/at PoE input would likely help me sell 1000 more AX2 routers this year.
I agree. Some kind of trusted panel/forum where MikroTik can get critical feedback and test ideas without going too far down the road. I am/have been a part of these kinds of alpha/beta groups with other vendors over the years and they are incredibly valuable.
I would only add that you’d want a mix of people on the panel, or a combination of panels to address the various sectors: large ISPs, small ISPs, fiber, wireless, MSPs/integrators/etc. (all people who actually touch the products on behalf of the end-user), as well as corporate end-users, large and small.
As already stated, put them under NDA, pick and choose those who have provided useful feedback in the past and have the right mix of stuff for you to test.
I think they’re caught between the “ROS has been able to run on virtually everything they sell" mentality (which is awesome) and the “we now sell 100 different things,” where the overlap between the things becomes less and less.
I have to admit, I’m in the hobbyist camp a little bit when it comes to things like ROSE and containers, and I am still excited to come up with a way to leverage that capability in SOHO routers.
But I do agree that some kind of segmentation or compartmentalization of features is beginning to make sense the more disparate the devices become.
Not being in this kind of space, I didn’t really consider the impact this causes. I was rapidly coming to the conclusion that the SOHO market wasn’t somewhere that Mikrotik wanted to be and that WISP and mass deployment was where it was at. I’ve given up trying to deploy Mikrotik in SOHO in UK as Unifi is simply easier. But sounds like they’re alienating that market too?
Most of us here really, really, really want Mikrotik to thrive and grow but the roadmap does seem a little confusing at times.
Brian, to be able to help you, we must be able to understand your goals. This is just common sense.
One thing seems to be incorrectly reported from time to time.
Devices that are upgraded, stay working with all features. Nothing is breaking upon upgrade. This is in the manual:
For devices running versions prior to RouterOS version 7.17, all devices use the advanced/enterprise mode.
So we are discussing new devices and how to improve deployment flow.
Outside of device-mode, for deployment of new devices and conversion of config from old to new device in general (user had an old MikroTik device and now has bought that shining new one), it would be helpful when:
- there is a good document that describes what commandline parameters are changes in which version. not so much about new features, but about existing features that now have new names or a different structure of configuration
- where possible, it would be nice when old parameter names were still accepted in new versions and then auto-converted, just like they are when the version is simply upgraded
- it would be very nice when /import and /system/reset-configuration with script would (optionally?) continue on execution errors, generating output with the offending line and the issued error message, writing this journal to a file when called from background (e.g. reset-configuration). as it is now, every minor error halts the import halfway, making it very difficult to write scripts to auto-configure new devices or to transfer existing config to a new device.
Just reading the changelogs shows that this statement is clearly incorrect.
And in advanced mode these items are disabled
(and it is also written in the changelog that these entries, which previously did not exist, are created disabled)
traffic-gen: no
partitions: no
install-any-version: no
routerboard: no
!) 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 (additional fixes);
The future concern is what if you introduce new device-mode's. Basically, there is not some "best pratice", nor knowledge of how future device-mode additions be handled.
For discussion, say provisioning process used a device-mode update mode=advanced container=yes fetch=yes schedule=yes on new hAPbe3 by integrator & the v7.21 config happens to uses /ip/packing on ISP uplink. Then future v7.25 comes along y'all decide "/ip/packing is dangerous" (just for example) ...and add new mode packing=no in that release.
If you're planning today, How would future =no going to be handled?
.e.g. Adding another twist in hypo...if only mode=home used the packing=no in v7.25, but mode=advanced allowed /ip/packing... and integrator's provisioning only used container=yes fetch=yes schedule=yes (so left mode=home)... now in v7.25 with defconf using /ip/packing, you did the "right thing" by limiting to device-mode to only needed, at the time. Or, you didn't bother to read about mode=. But now because you didn't change mode=advance... you'd be screwed.
So the mere possibility of this scenerio, means you should set mode=advanced today to cover yourself. But now you may be enabling a bunch of things that aren't need in case new logic in future.
... and this is why @BrianHiggins argues this needs to be controlable via Branding Kit, so if the 7.25 come along, a new branding kit could set the newly needed packing=yes in hypo. And doubt he uses packing... so could be some esoteric feature that someone might use