Default device-mode "modes" exhaustive list

RouterOS General
1

Hello everyone,

After getting used to device-mode, I was searching, without success, to find an exhaustive list of modes of device-mode, depending of the (brand new) router.

It is explaining on the documentation website (Device-mode - RouterOS - MikroTik Documentation) that brand new CCR and 1100 are going to be in "advanced mode" starting from 7.17, but there are no further explanation for other routers.

Some are described as "home router", and the remaining ones will be in "basic" mode.

But for example, in which category the hEX belongs to ? Is it or home router ? Or a Ethernet router ? If we look at the "Hardware" section on the main website, some category could be ambiguous.

Maybe someone has a list, or MikroTik published it somewhere.

Thank you,

2

As far as I remember, MT staffers explained that devices with factory default software version preceeding 7.17 (preceeding device mode fame) will all have mode=advanced. Only devices with factory default newer than that will see default setting of mode set to something different.
But I don't recall any mention of particular devices and their modes.

Anyway, even if mode is set to advanced, changing any of properties requires fiddling with device button or device powering ... and same principle applies to changing mode from basic to advanced. So I don't see a big problem if device comes in device mode other than a particular device admin would like to have it. Even less should be this a criterium when deciding on which device fits a particular use case.

3

I agree with the fact that the default "mode" should not be a criterium dealing with deciding which device fits the most in each case.

I have to prepare a lot of brand new routers, and routers coming back from customers, and to apply configurations, brandings,...

Depending of our configuration, some require RoMON, some others not, and go on.

So I was wondering if the future "factory device-mode" (for the moment we do not have routers manufactured with 7.17 or newer), will be an issue to resolve with our configurations and our procedures.

Of course, device-mode has to be set up complying with the right securities / functionnalities for each of our customers, but I was thinking about the routers that would not need any particular configuration.

4

Device mode will definitely affect your commissioning process. As does the new practice of having random factory admin password.

5

And there was my original request, asking for a list to be able to apply the right settings depending of the router :grinning_face_with_smiling_eyes:

Thank you for your answer,

6

Password is not a problem.

What does it matter to differentiate???

/system \
    device-mode \
    update \
    activation-timeout=60s \
    mode=advanced \
    flagged=no \
    flagging-enabled=yes \
    bandwidth-test=yes \
    container=no \
    email=yes \
    fetch=yes \
    hotspot=yes \
    ipsec=yes \
    l2tp=yes \
    pptp=no \
    proxy=no \
    romon=yes \
    scheduler=yes \
    smb=yes \
    sniffer=yes \
    socks=no \
    traffic-gen=no \
    zerotier=yes \
    install-any-version=no \
    partitions=yes \
    routerboard=yes \
    authorized-public-key-hash=""

In the future, when the "inventors" of the MikroTik nonsense want to get serious, they will use the serial number signed by the private key of the authorized-public-key to authorize changes remotely without sticking someone's finger up the button.

7

P.S.:

As things currently stand, device mode can be completely bypassed without any problems, provided one has access to administrator credentials...
So, all for nothing...

8

Thank you for your answer,

I know it is necessary to do further operations after the first apply of our configurations, but we have to adapt our scripts / procedures, that's why I asked for that list,

I will have to check myself which router will be "basic", or "advanced", or "home" from factory, then adapt my scripts.

9

Just read the status, and inside the script adapt the instructions flow.

Something can be applided with autodestructive script scheduler with instruction after key-press reboot...

10

I'd do this in reverse: pick the device-mode's you need, and set them explicitly to =yes. They have changed the meaning of mode in past, so I worry it might change again. And mode is more like an "profile", since you can always explicit set any of the device-mode item manually.

But for anyone who has to provision more than a handful of routers, the whole device-mode concept is flawed, overly complex in how mode works, and poorly implemented... The biggest problem is this cannot* be automated, since tools like netinstall or flashfig cannot do it. So a real person has to hit the button/power-cycle. I previously had scripts that could go from a router from box to ready to deploy with one command — with device-mode fully automated provisioning is now impossible...

*outside scripting some external device that recycles power from network

11

Aside from physically unboxing the RouterBOARD and plugging it in...
The script can "knock" the PoE switch and cause it to reboot... :grin:

12

Various modes, included new undocumented ROSE on 7.19.4

defaults for ROSE mode: (is like ADVANCED + container)

                 mode: rose         
     allowed-versions: 7.13+,6.49.8+
              flagged: no           
     flagging-enabled: yes          
            scheduler: yes          
                socks: yes          
                fetch: yes          
                 pptp: yes          
                 l2tp: yes          
       bandwidth-test: yes          
          traffic-gen: no           
              sniffer: yes          
                ipsec: yes          
                romon: yes          
                proxy: yes          
              hotspot: yes          
                  smb: yes          
                email: yes          
             zerotier: yes          
            container: yes          
  install-any-version: no           
           partitions: no           
          routerboard: no           
        attempt-count: 0

defaults for ADVANCED mode:

                 mode: advanced     
     allowed-versions: 7.13+,6.49.8+
              flagged: no           
     flagging-enabled: yes          
            scheduler: yes          
                socks: yes          
                fetch: yes          
                 pptp: yes          
                 l2tp: yes          
       bandwidth-test: yes          
          traffic-gen: no           
              sniffer: yes          
                ipsec: yes          
                romon: yes          
                proxy: yes          
              hotspot: yes          
                  smb: yes          
                email: yes          
             zerotier: yes          
            container: no           
  install-any-version: no           
           partitions: no           
          routerboard: no           
        attempt-count: 0

defaults for BASIC mode: (like ADVANCED without socks, bandwidth-test, traffic-gen, proxy, hotspot, zerotier)

                 mode: basic        
     allowed-versions: 7.13+,6.49.8+
              flagged: no           
     flagging-enabled: yes          
            scheduler: yes          
                socks: no           
                fetch: yes          
                 pptp: yes          
                 l2tp: yes          
       bandwidth-test: no           
          traffic-gen: no           
              sniffer: yes          
                ipsec: yes          
                romon: yes          
                proxy: no           
              hotspot: no           
                  smb: yes          
                email: yes          
             zerotier: no           
            container: no           
  install-any-version: no           
           partitions: no           
          routerboard: no           
        attempt-count: 0

defaults for HOME mode: (like BASIC without scheduler, fetch, sniffer, romon, email)

                 mode: home         
     allowed-versions: 7.13+,6.49.8+
              flagged: no           
     flagging-enabled: yes          
            scheduler: no           
                socks: no           
                fetch: no           
                 pptp: yes          
                 l2tp: yes          
       bandwidth-test: no           
          traffic-gen: no           
              sniffer: no           
                ipsec: yes          
                romon: no           
                proxy: no           
              hotspot: no           
                  smb: yes          
                email: no           
             zerotier: no           
            container: no           
  install-any-version: no           
           partitions: no           
          routerboard: no           
        attempt-count: 0
13

True, previously noted:

I'd add that OP could netinstall a known version, which is likely a good idea already & then set the device mode or individual values. Since the device-mode yes/no values used by particular mode should be same for all router at same version. Now as new version comes out, as @rextended notes, these can change... so possible you may still have to revise process in future. And it's that uncertainty that is particular galling..

14

I really like that idea,

Adding to the PoE switch that could be turned off when flashfig applied...

I guess I have everything to make something working with the future "factory device-modded" devices !

Thank you all,

15

Having been somewhat out of the loop for a while I was asked to set up a couple of units to be installed at remote locations so they can be used for bandwith testing etc. The network spans a huge distance using primarily DMR’s and more than a couple of sites are not easilly accessable so pressing the power button is just not an option.

If there is an issue somewhere in the network it makes it real easy to test and hone in on the problem wihout too many tears or organising a helecopter to get up to site.

In some cases I can see where this could be a great idea but certinaly not in ours. It would be nice to be able to dissable it and not rely on any form of buton press.

Saying that I am now wondering if its worth building a rube goldberg machine that I can connect to one of the spare ethernet ports, send a ping to is and have a ball bearing spiral down a wire knocking a roller skate that speeds across the floor and in to a rake that falls over knocking the button. The issue is then how to reset the rube goldberg machine.

It seems that we are not alone with our frustration on this topic.

Hopefully someone will see some sense and implament a “Hardcore Henry” mode for us.

16

For what it is worth, to solve that issue, I am testing using a small servo to push the reset button commanded by the "usr led" lighting of a hap lite.
But of course it is only a side-side amateur project, in my case particularly half-@§§ed.

In production I would look for an ethernet relay, powering the network device through the NC contact of the relay, would allow to send the "ON" command (which would actually be an "OFF" command), possibly with a delay.

17

I don’t know if physically pushing a button is necessary or if a power-cycle will achieve the device-mode change, but if a power cycle will suffice then the Shelly brand of programming relays would work very well.

I use these in remote-control/home-automation routines with Home Assistant, but they can be controlled and programmed/scripted without HA. I’ve found them extremely versatile and reliable.

EDIT:

Further, the shelly can be programmed to cycle power if it (the relay) loses network connectivity.

18

Yep, you confirm EITHER pushing the reset button OR power cycling.

IF the Shelly can be sent a "off-then-on-after-5-seconds" command (or something similar), it would do nicely.

The "normal" shellies are wi-fi only, so you would need a "pro" version that has the ethernet port.

And one of those costs more or less like a hex or hex s.

Most (not all) cheap ethernet relays you can find on Aliexpress have a timer that allows that.
Example only:
https://www.aliexpress.com/item/1005001729638858.html

If the Shelly can only be set on or off it won't do, as there is no way to connect to it once the router is off (or you need to add a relay/timer to resume after a few seconds).
Or maybe its sensing the connection off can be used, but I wouldn't persoinally use that, as it could create havoc is network is down for some other reasons.

19

The non-pro Shellys are indeed wi-fi, while the pro versions have an ethernet port and do indeed cost about as much as a lower-end hEX. How would you use a hEX to power cycle a router? Maybe if the router to be cycled is powered by via POE from the hEX?

Shellys can be told to cycle power remotely. They can also be programmed to cycle power if ping connectivity is lost.

20

While certainly lots of ways to rig up something... The underlying issue there is no way to "opt-out" once for those that remotely manage routers, since handling the "power cycle" with more hardware/accessories/PoE/etc isn't always practical.

MikroTik should have better solutions for the ISP/ISV/OEM crowd for device-mode. I just ran into this last week when trying to add zerotier (which is blocked by home) to a remote router, since I'd forgot some newer hAPax shipments had "home" mode set where zerotier isn't allowed. Solvable but PITA.

There are many of us that use "home" routers for non-home use cases in costly places to access, so this comes up. So while there is some point-in-time way to set "allow all", the lack of some way to guarantee that the scheme might change, again.