Ok MK, in New Zealand we’ve just started receiving ROS HW with 7.18 installed, and this came with the unbelievable brick wall of a monumental feature on how to seriously disrupt the workflow and ultimately instill disbelief and make grown men cry for those of us who work in the WISP industry and install 100’s of Mikrotik home routers a year.
The first inconvenience was the enforced admin password that you can’t read on the sticker without a magnifying glass, but this hardware mode takes the biscuit.
As a network engineer I use the bandwidth tool daily to diagnose performance issues between our main gateway routers and a customers. Now for me to be able to use this very useful and important feature I now have to ensure all new MK’s we get have to be changed from home to advanced routers, or ensure someone is onsite to physically turn off the power while I change the mode because it wasn’t picked up before.
This device mode idea is a total an absolute fucking spit in your users face. I get the security concern, but for real, what statistics of abuse do you have to justify making this feature live without customer consultation?
If there is anyone sane left in this company, revert this stupid device mode feature and allow all features on all your devices as normal.
Peace out, as now I need to go walk around the block to cool off.
Agreed. I've screamed about this since it first appeared in some beta.
Basically they forced all system integrator into using netinstall on new devices. There is a trick in to put the device-mode command as last in the netinstall script. In our case, we use branding kit to provision CPE routers, and /system/reset-configuration to get it apply. Simple and easy, no netinstall so someone in field could just follow a few steps. Now it is a container with netinstall, and making sure each new unit gets that treatment when they come in, which is PITA since it means we cannot drop-ship things to a customer.
And for sympathy, see discussion here:
And I too have been burned by this of late, since zerotier used to be allowed by default but newer units it's not. We use ZT as the management backbone, so it's a big problem. We have several in field that we had to manually setup WG to get to the devices, since I'd forgotten they were a newer batch.
Thanks for the link Amm0. It appears that MK are a group of stubborn up their own arse, our way or the highway producers.
I’m quite happy to spend the time it takes to re-configure any new MK hAP’s in convincing my boss to drop this shit show and go with another outfit. One that engages. GWN is on the radar for that matter.
In case bandwidth-test is heavily used in your setups, then we suggest during initial configuration of the device (when it is not installed on premises yet), enable bandwidth-test=yes on device-mode configuration.
It will help to avoid unnecessary hassle in the future.
I agree that the requirement for physical intervention (power cycle or pressing button) to change device-mode is a major burden in batch device deployments. Is it possible to change this requirement to something that can be performed via commands only?
I also agree that the password font is too small for us over 45. Please Mikrotik, make it larger!
I, too, have had some pretty annoying experiences with it - going into someones house or business is usually okay as you can get them to reboot whilst on the phone, but some of them have gone into remote shacks etc that is quite an effort to get someone back to.
I would be less annoyed if there was some way to do it (even if its re-authenticate or something) from the CLI.
@jwab For your existing deployed devices: As far as I know, existing devices default to device mode "advanced". This mode still allows bandwidth test tool. This is what you described you are using heavily.
Factory new devices probably come with another profile depending on device. Maybe you see "home" device mode here. But when provisioning brand new device, I know it may a new step in provisioning, but: just enable all device mode properties when initial provisioning. Then ship your device to customer. Don't have to fiddle afterwards.
I don't see the big issue here and not a reason for a "walk around to cool off". It is a small PITA.
Big PITA have people who are using traffic-gen on already deployed devices for some reason. They have to bite the bullet.
It seems the rationale for introducing this device mode is based on the desire for explicit user engagement (notification) about enabling this mode. Why not use some scary red indicator on the device instead of relying on power? Power can also be compromised (hacked) in smart plugs and PoE devices.
Or what's stopping me from enabling the extended mode every 5 minutes in the scheduler, so that I can end up getting it the first time I accidentally turn off the power?
Whether it is a home device, or a CCR in a datacenter serving mission critical services - when I want to use a command to do something, I want to use a command to do something. I dont want to 1) unneccessarily reboot a device, or even worse 2) send someone out to push a button.
You’re selling me a car with 5 gears, but I am only allowed to use 1st.
@normis The issue of our (W)ISP colleagues is that they are now forced to change the way they perform initial provisioning of devices they hand out to their customers.
before device-mode settings were made quite strict (and before default admin password became non-empty) they could ship devices uprovisioned to customers and do the whole provisioning remotely.
Alternatively they could do some batch / automatic configuration in their workshops ... which only included connecting each device to switch and run a script ... it was possible to do it in batches without further physical interaction.
after the device-mode change (and with default admin password set), this gets quite complicated. Remote provisioning is only possible if one knows admin password (good!) and only if device-mode is already set appropriately. When provisioning devices in workshop, it's necessary to enter admin passwords ... and cut the power to each unit individually to make device-mode changes stick
And this additional manual work, while not complex and not really intrusive when dealing with single device, is what makes mass provisioning a major PITA.
I don't think that what @jwab writes is anything new from discussions we've had in the past ... then MT stubbornly ignored the issues people described (saying that they were non-issues) so I'm not expecting any other response now.
I did. Whether it works on existing devices or not is irrelavent. The point is it wont work on new devices. All of this, can very easily be done with simply expanding /user/groups - which is software configurable.
Unless that has changed very recently, device-mode locked features only remain working on already deployed devices until a RouterOS upgrade is done on those devices.
Is the official MikroTik stance now that you should not upgrade RouterOS on already deployed devices?
Only thinking aloud (I already know that it will fall on deaf Mikrotik ears anyway), it should be possible to program the stupid device mode to be "all enabled" until the factory password is used?
The normal (old) procedure (for WISP) should have been:
access the router with admin and blank password
change the blank password to a "secure" one
set the configuration
(#2 and #3 could be exchanged)
The new one could be:
access the router with admin and factory (stupidly printed in unreadable characters) password
set the configuration
change the factory configuration password to a "secure" one
with this #3 step the device mode becomes active (without needing a reboot or button press) automagically
!) 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;
If you upgrade to 7.17+ - this is what happens: you can't traffic-gen, can't repartition (but still switch partitions) and can't downgrade below certain ROS version (7.13,6.49.8). Everything else remains as before allowed. How many use traffic-gen, how often do you repartition a deployed device and why would you want to downgrade to e.g. 7.11 or 6.47?
Well, you are not free to use the above sequence, when you first login to a router it will demand you to change the password.
Also MikroTik probably want to “protect” those routers that are connected without every being logged on to. When you have an ISP that has ethernet+DHCP as the user connection you may be able to use a MikroTik home device without ever touching it (when you use the default WiFi SSID and password).
Maybe the device-mode could be enabled only after the first reboot. So you could start a router, log in, set password, set device-mode (without the button/powercycle requirement) and use it, and after the first reboot the device-mode would stick to what is set and can later be changed only via button/powercycle.