Device Mode hell

Just to seperate problems here... I see three theme:

  1. out-of-box provision to set needed device-mode is "hard" and/or manual
    e.g. lack of netinstall/branding/flashfig control of device-mode

  2. How to allow device-mode changes in field "safely" and without requiring the power-cycle
    e.g. lack of some "key" or alternative scheme to allow remote changing device-mode without power cycle)

  3. How to plan for future device-mode changes, when "rules" are unknown
    e.g. @rextended point above, gist of @BrianHiggins points about the "rug being pulled" with breaking future changes in device-mode and 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-mode setting, 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 same device-mode. So it now added another scenerio to plan/test. Now perhaps factory-version restricts that... but IDK... since it's not document how a mode work 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.