@normis Updating from 7.21.2 to 7.22rc1 on a hAP ax S after restarting, I was surprised that the leds for the wifi were both turned OFF. No changes were made to the config on this upgrade. After switching back to the previous version and the wifi leds were back ON again. This is a bug.
Are you sure? Maybe it was a change in how things are configured. We have not seen your /system leds configuration and it could be that configuration is now required for those leds (although usually that would be created automatically when upgrading like this).
wifi - fixed functionality of the wireless-signal-strength LED trigger;
Here’s my /system leds export
# 2026-02-09 18:21:52 by RouterOS 7.21.2
# software id = NPI8-P24B
#
# model = E62iUGS-2axD5axT
# serial number =
/system leds
add leds=poe-led type=poe-out
And this is how it looks like when printed
Flags: * - DEFAULT
Columns: TYPE, INTERFACE, LEDS
# TYPE INTERFACE LEDS
0 * interface-activity sfp1 sfp1-led
1 * interface-activity ether2 ether2-led
2 * interface-activity ether3 ether3-led
3 * interface-activity ether4 ether4-led
4 * interface-activity ether5 ether5-led
5 * wireless-status wifi1 wifi1-led
6 * wireless-status wifi2 wifi2-led
7 poe-out poe-led
It says wireless-signal-strength, the leds are by default configured for wireless-status on this device as you can see above. This change might have adversely affected the existing leds function on this device in this upgrade.
The issue with BGP-VPNv4 redistributing "other BGP" multihop routes to other PE via RR is still occurring in version 7.22.rc1 [SUP-207808]
That seems OK. So maybe there indeed is a bug.
Note that you can configure the LEDs to do anything. Also note there is a setting to turn off the LEDs after some time (but when your export is complete you have not set that).
I am seeing a kernel panic when attempting to upgrade a CHR from 7.22beta6 to 7.22rc1.
2026-02-09 13:17:24 system,error,critical kernel failure in previous boot
After applying the update, the device reboots, kernel panics, and then reboots again, reverting to 7.22beta6.
Yup, same; still not fixed in rc1 for me either.
However, my own ticket just got closed a few hours ago with a message saying the issue is fixed and the fix will be included in an upcoming release.
According to Mikrotik support the fix will be included in v7.22rc2..
Hi All,
Will auto generation of BGP blackhole route be removed in V7.22.x?
Update, we've downgraded PE to version 6.49.19 and BGP-VPN4 successfully advertises the multihop BGP prefix to RR/other PE. The ticket and PE supout for version 6.49.19 have been sent to support@mikrotik.com, hoping for some insight into this issue 
.
There is a setting for it, but it does absolutely NOTHING. I.e. the blackholes are created no matter how you set that.
I noticed that when a BGP connection has only “connect” and no “listen” option, it will fail to establish.
It is not true, setting disables generation of active blackhole route.
it's true, output.network-blackhole=no does nothing, still multiple blackhole routes with distance of 255 for each session
BFD sessions seems broken over IPv4, IPv6 is fine. Scheme is R2 (beta5) ←> R1 (rc1) ←> R3 (beta5)
On R2: sessions shows state=down, 0 Rx, have Tx
On R1: sessions shows state=init, have Rx, have Tx. Torch shows no outgoing BFD packets on interface, only packets from R2/R3
On R3: same as R2, state=down, 0 Rx, have Tx
It does not work. I tried both settings (checkmark and no checkmark) but it keeps generating the blackhole routes!
Also during testing I found an issue when connect is set and listen is not, then it will log “incoming connection” from the other side (which has only listen!) and it does not work. That probably started in an earlier beta.
Please read again it disables generation of ACTIVE blackhole route. There will be BGP NET route in any case.
We want an option to stop that silly auto-generated blackhole route for advertised prefixes!
Especially because it was implemented at the wrong level. There is a blackhole generated per advertised network FOR EVERY BGP CONNECTION, that can sometimes be tens of connections.
It wasn’t there before, it serves no useful purpose, we want it GONE.
- it pollutes the routing table
- it removes functionality: to have synchronized routes that are only advertised when that network is up and running
- it adds absolutely nothing. when people want to advertise networks without having a local route, have them add the blackhole route themselves. put that in the documentation.