I have same problems on Hex and Hex S with 7.18.2.

Hi,

Ipsec or sfp is running?

Note that the procedure to update the backup bootloader at https://help.mikrotik.com/docs/spaces/R ... bootloader has now been updated to support version 7.18.2 (ONLY!) so when you get those warnings about NAND stability after an upgrade, now is the time to upgrade the bootloader to fix that.
(before, it required version 7.6 which is of course ancient and nobody wants to downgrade to that)

List of supported hardware for upgrade factory-firmware code

PPC
mpc8544
p1023
p2020
UNSUPPORTED: mpc8548, mpc8343, mpc8323, amcc460

TILE
tilegx

MMIPS
mt7621L

SMIPS
qca9531L

MIPSBE
ar7100 (only some models)
ar7240 (only some models)
ar9330
ar9330L
ar9340
ar9340L
ar9344
ar9344L
qca8513 (MUSIC)
qca8513L (MUSIC)
qca8719L (MUSIC)
qca9531L (is the same for SMIPS)
qca9550
qca9550L
UNSUPPORTED: qca9531

ARM
ipq8060 (only some models)
UNSUPPORTED: ipq4000, ipq4000L, dx3230L, al2, ipq5000, en7562, mdm9607

ARM64 / AMPERE
70x0 (Armada)
UNSUPPORTED: al63, al64, al64v3, al64B, a3700, ipq9574, ipq6000, ipq5300, ipq807x, dx2528

x86
UNSUPPORTED: rb230

MIPSLE
UNSUPPORTED: <ALL>

Note that the procedure to update the backup bootloader at https://help.mikrotik.com/docs/spaces/R ... bootloader has now been updated to support version 7.18.2

[admin@RBD25G audience] > /system/routerboard/print
       routerboard: yes
        board-name: Audience
             model: RBD25G-5HPacQD2HPnD
          revision: r2
     serial-number: <snip>
     firmware-type: ipq4000
  factory-firmware: 6.47.9
  current-firmware: 7.18.2
  upgrade-firmware: 7.18.2
[admin@RBD25G audience] > /log/print
 2025-05-09 18:51:10 system,info installed bb-upgrade-7.18.2
 2025-05-09 18:51:10 system,info FAILED to upgrade backup booter: Unknown RB
 2025-05-09 18:51:10 system,info router rebooted by ssh:admin@192.168.42.10

Doc says it's universal ... but doesn't seem to be that universal ...

your factory-firmware version is lower than 7.18.2 and your device displays the message → The "protected routerboot" feature requires a backup-routerboot upgrade ← when trying to enable the feature, do the following

There is more underneath (unsaid, don't ask) that makes it worth updating.

..[CUT]..
Remember when something goes wrong during the upgrade, your device is bricked.

..[CUT]..
Remember when something goes wrong during the upgrade, your device is bricked.

And do not bother trying to upgrade 16MB flash devices ..

I don't think upgrade of backup routerboot (factory firmware) has anything to do with available flash space..

I don't think upgrade of backup routerboot (factory firmware) has anything to do with available flash space..

nope, it definitely does ..take a second look at my picture

 2025-05-11 09:06:35 system,info installed bb-upgrade-7.18.2
 2025-05-11 09:06:35 system,info FAILED to upgrade backup booter: Unknown RB

In my small lab, this version 7.18.2 runs incredibly stable and reliable on the CCR1009. It will definitely stay on for longer.

If your RouterOS is v7, your factory-firmware version is lower than 7.18.2 and your device displays the message → The "protected routerboot" feature requires a backup-routerboot upgrade ← when trying to enable the feature, do the following:

Or are we saying there is some other hidden benefit in performing this procedure, and the unsupported devices are missing out on something?

You missed the point, there was no warnings before upgrade or i ever touched CPU freq on this fresh unpacked device , its the upgrade which changed freq or whatever it did and now complains about "it self"

The upgrade didn´t change frequency. It changed You ability to change frequency between "auto" or "$VALUE" without manual intervention. If it was "auto" before the upgrade, it will still be on "auto" after, and the up/down auto scaling will still happens. If it was set on a given fixed frequency, it will still be on that one.

The difference is that NOW You need physical access in order to change the setting. And there is one place "/system/device-mode/" where You can change this behavior - again, physical access is needed to make the change.

1. May i know how to get into /system/device-mode/ to adjust the CPU frequency, please?

2. In case it is difficult to get into /system/device-mode/, to which version i need to downgrade so i can reget the function to adjust the CPU frequency?

Upgraded L009UiGS-RM from 7.16betasomething, installed qcom-ac, reboot, uninstall qcom-ac as I've found it wasn't needed to setup CAPsMAN for qcom-ac devices, reboot, set wifi stuff, enable CAPsMAN, reboot -> dead.

1. May i know how to get into /system/device-mode/ to adjust the CPU frequency, please? It sucks to to lose functions which working fine at previous version.

Hi all,

I was find many many BUG's in soft.
Firsth:
Netwatch not working but in version 7.17.2 it still worked and now it doesn't work ;) :D
] > ping 85.14.118.245 src-address=85.14.118.246
SEQ HOST SIZE TTL TIME STATUS
0 85.14.118.245 56 255 901us
1 85.14.118.245 56 255 1ms286us

My Netwatch is working on dozens of different MT devices with the last (and many previous) version(s) without any problem.

[@MT-Router] > tool/netwatch/print detail

Flags: X - disabled

0 ;;; WAN Interfaces Monitor 
host=85.14.118.245 type=icmp src-address=85.14.118.246 interval=10s startup-delay=20s 
up-script=/routing rule set [find src-address="0.0.0.0/0" and table="maintwo"] disabled=yes\r\npause 1\r\n ip firewall/connection/remove [find] 
down-script=/routing rule set [find src-address="0.0.0.0/0" and table="maintwo"] disabled=no\r\npause 1\r\n ip firewall/connection/remove [find] test-script="" ttl=2 http-codes="" 
status=up

/tool ​​netwatch disable $i
:delay 5
/tool ​​netwatch enable $i

[@MT-Router] > system/resource/print
                   uptime: 1w1d7h29m22s       
                  version: 7.18.2 (stable)    
               build-time: 2025-03-11 11:59:04
         factory-software: 7.6                
              free-memory: 15.3GiB            
             total-memory: 16.0GiB            
                      cpu: ARM64              
                cpu-count: 16                 
            cpu-frequency: 2000MHz            
                 cpu-load: 1%                 
           free-hdd-space: 56.4MiB            
          total-hdd-space: 128.0MiB           
  write-sect-since-reboot: 209648             
         write-sect-total: 15416247           
               bad-blocks: 0%                 
        architecture-name: arm64              
               board-name: CCR2116-12G-4S+    
                 platform: MikroTik

..[CUT]..
Remember when something goes wrong during the upgrade, your device is bricked.

And do not bother trying to upgrade 16MB flash devices ..

I asked about the importance of that "Optimal nand stability requires a backup-routerboot upgrade" message but never got an answer.

To avoid having problems like in other topics, it's better to update while you can... ignoring whether one uses that feature or not.
There is more underneath (unsaid, don't ask) that makes it worth updating.

The problems start when you start using the field "src-address"

I have no problems with that, but probably you have more special config than that, like multiple routing tables, routing in mangle rules, VRF, or whatever similar.

I have no problems with that, but probably you have more special config than that, like multiple routing tables, routing in mangle rules, VRF, or whatever similar.

I'm trying to understand how RoS chooses the src IPv6 address, when starting one connection. I have several Wireguard tunnels, all of them using /127 ranges. Sometimes, when the router itself will make a DNS request, it uses the address from (say) wirguard1 - but uses wireguard2 as the gateway! Yes, every wireguard tunnel has one ULA IPv6.

There have been bugs in that, I don't know the current status.

*) firewall - fixed IP/Settings "ipv4-fasttrack-active" status showing as inactive when it is active;

It's fixed in 7.19

*) firewall - fixed IP/Settings "ipv4-fasttrack-active" status showing as inactive when it is active;