I have RB5009UPr+S+. For testing purposes, I’ve switched CPU Frequency in RouterBOARD settings from Auto to 1400MHz. I want to revert it, but I cannot do that - getting “not allowed by device mode: ()”:
I’m running 7.17.1 and the device is in 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: yes
install-any-version: no
partitions: no
routerboard: no
attempt-count: 0
However, I don’t think that’s expected behavior, is it? It’s OK if this requires updating the mode, but then it shouldn’t allowed me to change the frequency from “Auto” in the first place.
As of 7.17 it is as Mikrotik is trying to lock down features that can be abused by hackers and other nefarious actors. This change has been quite the lightning rod for complaint and anger but it doesn’t look like they’re going to change things. You’ll have to run commands for specific features you want to turn on/off and then reboot the device by pulling the power or pressing reset button. Now image having to do that same thing with 100s or 1000s of fielded devices…
7.17.1. That’s why it’s strange. If I had set this using older version and couldn’t revert after upgrade, it would make sense. Now, I changed it, but couldn’t revert it back after a couple of minutes. The router wasn’t even rebooted during that time.
@tdabasinskas this is a bug IMHO. I have experienced this bug as well. I did came up with some test cases and reported them all to Mikrotik support this week. SUP-177436
Depending on your action sequence there is a high chance that rebooting (/system/reboot) reverts cpu-frequency back to “auto” magically. Give it a try.
I prefer not to go into detail regarding my observations and the test cases I used to reproduce this issue, as I believe it could be security-sensitive. Additionally, it is unclear whether this bug is limited to CPU frequency adjustments or if it represents a broader flaw affecting other device-mode restricted settings. I have not investigated further, as repeatedly cycling device modes via the mode/reset button is not practical for extended testing.
MikroTik Support thanked me for reaching out and for the report. They mentioned that they had reproduced the issue and were looking forward to fixing it in future RouterOS versions.
What's new in 7.17.2 (2025-Feb-06 11:10):
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
Having to physically turn off the power or press a reset button seems crazy. I’m remotely administering the RB at my parents’ home on another continent, half-way around the globe.
I’m not sure your post illustrates the persistence of the problem.
The way things are supposed to work:
print of routerboard settings will didpkay warning if CPU frequency is not set to default. And setting CPU frequency on ROS v17 and later is only allowed if device-mode property routerboard is enabled.
The problem: with initial 7.17 (and 7.18?) versions it was possible to set CPU frequency once even if routerboard property of device-mode was disabled.
The bug-fix: with 7.17.2 it’s no more possible to set CPU frequency once when routerboard property of device-mode is disabled.
Related behaviour: running config is never (well, almost never) changed by ROS upgrade. Which includes CPU frequency setting. What does change with ROS upgrades are default settings[*] … which affects output of export command - it displays settings which are setting device away from defaults (of any particular ROS version currently running). And print output is affected as well (in this particular case it displays the nasty warning about CPU frequency setting).
One has to manually change settings (e.g. to conform to new defaults) … but with this bug it was not possible (because one has to enable routerboard property of device-mode which can be a problem this way or another). For users who were affected by the bug (they changed CPU frequency setzing whrn this was not supposed to be pissible) the bug fix doesn’t change anything … to revert CPU frequency to former setting they’ll have to follow the same procedure as they had to with “affected ROS version”.
[*]two examples:
around version 6.45 CPU frequency setting “auto” (meaning kernel can dynamically change CPU frequency depending on CPU load) became available on certain devices. A version or three later it became default so all devices with static CPU frequency setting (previous default) started to display the warning (not sure when the warning display was introduced, I don’t think it was displayed previous to “auto” setting).
around version 6.43 default ethernet port speed changed ftom 100Mbps to 1Gbps. Previusly export command showed the setting if port speed was set to 1Gbps, afterwards it showed the setting if it was set to 109Mbps (previous default) even on devices e+with 100Mbps ethernet ports. RIS upgrade did not touch tge setting … and it did not affect anybidy … most users used autonegotiate=yes which doesn’t care sbout speed setting anyway. And for those with disabled autonegotiation any automatic change of settings could be fatal.
Anything working to lower my CPU speed so to lower the CPU temperature too, sadly the command not working…
I chose to turn off/on power. What is mode button? I don’t want to risk and press reset…
OK, after second time rebooting, finally i can dial down my CPU speed, thanks.
