Just to seperate problems here... I see three theme:
-
out-of-box provision to set needed
device-modeis "hard" and/or manual
e.g. lack ofnetinstall/branding/flashfigcontrol ofdevice-mode -
How to allow
device-modechanges in field "safely" and without requiring the power-cycle
e.g. lack of some "key" or alternative scheme to allow remote changingdevice-modewithout power cycle) -
How to plan for future
device-modechanges, when "rules" are unknown
e.g. @rextended point above, gist of @BrianHiggins points about the "rug being pulled" with breaking future changes indevice-modeand need for better communications about changes
On problem 3...
@rextended points out mode=rose exists, but this opens:
- MikroTik cannot be bother to even update the docs when messing with
device-modesetting, even though folks are "sensitive" on the topic... - And, now I dunno what happen is
mode=rose(or future one) is used, but system downgraded to 7.18.x without the samedevice-mode. So it now added another scenerio to plan/test. Now perhaps factory-version restricts that... but IDK... since it's not document how amodework if it does not exist on a version.
Yes. MikroTik knows there user policy controls are limited, and defaults too permissive...which how old device were a target for attack. But instead of fixing the user policy beyond sensitive=yes/policy=yes to allow more feature-level blocking... we got this mess of device-mode.
But "hastily" is not the right word. Since instead of working on new policy system, MikroTik is "looking at" fixing up device-mode.