I just disabled the graphics. Will report tomorrow.
I made an interesting observation these days while I was preparing some of my devices to hand over to new owners, if you perform a reset to default configuration using the reset button (Press the button and apply the power, then release the button when green LED starts flashing, to reset RouterOS configuration to defaults), not only the count of sector writes since last reboot, but also the count of total sector writes gets set back to 0 again 
This doesnât happen with Netinstall, and also not when clearing all configuration and defaults (release the reset button when the LED turns solid green).
I saw this on two different CCR and two different CRS devices of mine with ROS 7.22.2, thus works probably on any device. No idea whether other ROS versions are behaving the same way
I guess this was originally not intended to work this way, as it sets devices a sort of back into a virgin state.
Usually, cars have their odometers rolled back before they're sold. Now we'll be doing the same for Mikrotiks. 
Depends on HTTP server/Web service and how is list provided over it (if is dynamically generated or loaded from FS, etcâŚ), for example Github hosted list doesnât have last-modified header:
curl -I "https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts"
while from other service have:
curl -I "https://adaway.org/hosts.txt"
but both have etag cache header, so it is possible to get if list is not modified by sendig value from such header into if-none-match header in HEAD request, example:
curl -I -H 'if-none-match:"2f55e6b1a0ad5d136aba3e2e10e17906f63624d6f663a8abd48a2b2dd455c724"' "https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts"
and if response is HTTP code 304 (Not Modified) then list is unchanged. In sucn case ROS needs to persist per list etag header value from fetch when modified (when HTTP code 200 is returned from HEAD request) so that can perform etag cache header check logic before data fetch.
Not sure if that is implemented in ROS, not using its Adlist feature.
SUP-215499
Hi,
Iâm experiencing Tx Queue Drops on the QSFP interface on x86_64, and Iâm unable to resolve the issue.
Iâm not sure what might be causing it.
An /export would have been enough to solve the problem... as usual config related issue...
Then, for the others too, how many entries do you have in DHCP and how often do the leases expire?
we have the same exact issue, and we are unable to use multi-queue-ethernet-default to fix it because in fact we get KernelPanic and the router crashes and reboot.
Experiencing the same identical behavior on ARM64 platform and Ampere CPU.
SUP-214471 for x86 platform
SUP-189835 for ARM64
both confirmed by mikrotik but not fixed
CCR1009-7G-1C-1S+ running version 7.22.2
When I issue the following directive I should get all the physical ethernet interfaces but what i get is only a subset:
/interface/ethernet/export file=disk2/ethernet terse
2026-05-06 05:51:07 by RouterOS 7.22.2
software id = 1TLQ-B555
model = CCR1009-7G-1C-1S+
serial number = redacted
/interface ethernet set [ find default-name=ether1 ] disabled=yes loop-protect=on rx-flow-control=auto tx-flow-control=auto
/interface ethernet set [ find default-name=ether2 ] advertise=10M-baseT-half,10M-baseT-full,100M-baseT-half,100M-baseT-full,1G-baseT-half,1G-baseT-full comment=WAN loop-protect-disable-time=30s
/interface ethernet set [ find default-name=ether3 ] disabled=yes
/interface ethernet set [ find default-name=ether4 ] disabled=yes
/interface ethernet set [ find default-name=ether5 ] disabled=yes
/interface ethernet set [ find default-name=ether6 ] disabled=yes
What I should get is ether1 through ether7, combo and sfp-sfpplus1
MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK
MikroTik RouterOS 7.22.2 (c) 1999-2026 https://www.mikrotik.com/
Press F1 for help
[halo@Stargate] > /interface/ethernet/print
Flags: X - DISABLED, R - RUNNING
Columns: NAME, MTU, MAC-ADDRESS, ARP
NAME MTU MAC-ADDRESS ARP
0 combo1 1500 64:D1:54:D5:16:C6 enabled
1 X ether1 1500 64:D1:54:D5:16:C7 enabled
;;; WAN
2 R ether2 1500 64:D1:54:D5:16:C8 enabled
3 X ether3 1500 64:D1:54:D5:16:C9 enabled
4 X ether4 1500 64:D1:54:D5:16:CA enabled
5 X ether5 1500 64:D1:54:D5:16:CB enabled
6 X ether6 1500 64:D1:54:D5:16:CC enabled
7 R ether7 1500 64:D1:54:D5:16:CD enabled
8 sfp-sfpplus1 1500 64:D1:54:D5:16:C5 enabled
[halo@Stargate] >
You need to include verbose to your command to get all entries including those with only default settings.
/interface ethernet export file=disk2/ethernet terse verbose
It's always been this way, ever since "compact/verbose" existed and the default became "compact".
It's not related to 7.22.2, so there's no point in reporting it in this topic.
THAT Does not mean its the right way ⌠the right way is the way âprintâ displays it when exporting to a file âŚ
IMHO it is "the right way" already. Without "verbose" the defaults are omitted.
@mozerd
Right way or not, it's irrelevant about the 7.22.2 release.
And if I do an export (compact), it's only fair that it doesn't return unnecessary information like unchanged default parameters.
"Verbose" is there for that. Use it.
Please keep this forum topic strictly related to this particular RouterOS release.
The WPS button blue light stopped working on my hAP ax3. The indicator lights up when the router reboots, meaning it is working, but then goes out. Previously, it was constantly lit, regardless of the WPS settings in Wi-Fi interfaces. Toggling WPS for the interface does not make any difference.
Otherwise, everything works fine. The upgrade path was as follows:
7.20.8
7.21.4 - the router wasnât stable, stopped passing traffic for Wi-Fi clients and reconnecting was required
7.22.2
Youâre actually right; didn't notice this before.
The Blue LED is only on during boot. This is also present in 7.23.
Upgraded RB5009UPr+S+ which has a Draytek Vigor2927 connected on ether5 from 7.21.3 to 7.22.2.
After that, users of the Draytek report no internet and it appears that the transmit side of ethernet fails shortly after boot. The Draytek successfully gets an IP address, and traffic from users behind the Draytek is visible on the RB5009, but traffic from the RB5009 to the Draytek is not received.
Link is established OK at 1Gbps. Downgrade to 7.21.3 (switch partitions to copy made before upgrade) fixes it. I will try to do more debugging. Anyone seen anything like this?
Maybe it has something to do with âswitch - disable EEE on RB5009 and CCR2004-16G-2S+ devices;â on 7.22.1? It seems that it worked OK after the upgrade but it failed when the power was cycled after that (on both the RB5009 and the Draytek at the same time).
Replying to myself - last version where the LED works is 7.21.4.
SUP-215924