Unsolicited BSS Transition is already documented. see WiFi - RouterOS - MikroTik Documentation
3 Likes
Well, I think the reasoning is that because RouterOS v7 no longer offers the option of advertising an arbitrary piece of address space that does not have a corresponding route in the route table (which RouterOS v6 could do by unchecking the “synchronize” option), and RouterOS v7 also does not offer route aggregation, the helpdesk got lots of questions like “how can I still do that” and got tired of giving the answer “create a blackhole route and advertise that”. So someone got the idea of putting those routes in the table automatically so one could simply advertise them.
But as you rightly point out, it is not the same and it is not good to force doing that, it should be an option. Now they changed it that you have the option to advertise it or not but it is still installed in the table.
And there in lies the problem.
The correct way to do it, as you stated, is to create a blackhole route and advertise it. The entire internet community uses that… Why re-invent the wheel, and even more so, re-invent it in a way that breaks things for those that ARE doing it correctly…
This change in it’s entirety, should be removed. I will not run (and I am sure others too) a router that spontaneously, out of it’s own, start messing with my routing tables.
2 Likes
Yes, it is actually quite surprising that they did this. I agree it would be cleaner to roll it back.
Before I requested an option for a user-added second route table (not a VRF) to automatically include connected routes, preferably using an interface list that lists the interfaces for which the routes should be automatically included. They would not do it, I have to do it manually when I want that. Or use VRF, which has limitations.
But now they automatically add routes that we do not even want to have…
A rather strange situation after updating hAP AX3 to 7.21beta2.
An IP camera is connected to the 4th port of the router.
A video recorder is connected to the 5th port.
The bridge settings that worked before 7.21beta2 are as follows:
# 2025-10-08 13:05:38 by RouterOS 7.20
# software id = XFG1-GJIY
#
# model = C53UiG+5HPaxD2HPaxD
# serial number =
/interface bridge add admin-mac=XX:XX:XX:5D:41:FF auto-mac=no mvrp=yes name=bridge1 priority=0x1000 vlan-filtering=yes
/interface ethernet set [ find default-name=ether1 ] comment="Maxnet ISP" mac-address=XX:XX:XX:E5:1A:BA
/interface ethernet set [ find default-name=ether2 ] comment="Mikrotik RB750Gr3"
/interface ethernet set [ find default-name=ether3 ] comment="Mikrotik RB2011UiAS-2HnD"
/interface ethernet set [ find default-name=ether4 ] comment="IP camera"
/interface ethernet set [ find default-name=ether5 ] comment=NVR
/interface vlan add interface=bridge1 name=vlan-99-Lan vlan-id=99
/interface vlan add interface=bridge1 name=vlan-111-Guest vlan-id=111
/interface ethernet switch set 0 cpu-flow-control=yes
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4 mvrp-applicant-state=non-participant pvid=99
/interface bridge port add bridge=bridge1 interface=ether5 mvrp-applicant-state=non-participant pvid=99
/interface bridge port add bridge=bridge1 edge=yes interface=wifi1 mvrp-applicant-state=non-participant pvid=99
/interface bridge port add bridge=bridge1 edge=yes interface=wifi2 mvrp-applicant-state=non-participant pvid=99
/interface bridge port add bridge=bridge1 interface=wifi3 mvrp-applicant-state=non-participant pvid=111
/interface bridge port add bridge=bridge1 interface=wifi4 mvrp-applicant-state=non-participant pvid=111
/interface bridge vlan add bridge=bridge1 tagged=bridge1 vlan-ids=99,111
After updating to 7.21beta2, any of the connected devices (camera or video recorder) on the 5th port of the bridge stop receiving an IP address from the DHCP server.
However, any of these same devices (camera or video recorder) connected to the 4th port receive an IP address normally and are accessible over the network.
Returning to version 7.20 solves the problem.
And one more thing: if you connect any hub to the 5th port in 7.21beta2 (I tried hAP ac2, all of whose ports are in the form of a single bridge, and HP 1910), and a camera or video recorder through it, everything works normally.
Hi,
Please share the output of /interface/bridge/vlan/print
Is the DHCP server configured on "vlan-99-Lan" interface or somewhere else on VLAN 99?
Does the hub (hAP ac2) gets the IP address when connected to ether5?
Does disabling MVRP make any difference?
I did not reproduce the same behavior in our labs, please generate supout.rif when issue is active and send it to support@mikrotik.com.
The following apps are now included:
/apps:
total 332
-rwxr-xr-x 1 root root 1531 adventurelog.yml
-rwxr-xr-x 1 root root 502 babybuddy.yml
-rwxr-xr-x 1 root root 595 backrest.yml
-rwxr-xr-x 1 root root 384 caddy.yml
-rwxr-xr-x 1 root root 409 chr.yml
-rwxr-xr-x 1 root root 320 cinny.yml
-rwxr-xr-x 1 root root 337 cloudflared.yml
-rwxr-xr-x 1 root root 633 code-server.yml
-rwxr-xr-x 1 root root 746 conduit.yml
-rwxr-xr-x 1 root root 439 convertx.yml
-rwxr-xr-x 1 root root 966 copyparty.yml
-rwxr-xr-x 1 root root 890 docmost.yml
-rwxr-xr-x 1 root root 447 elasticsearch.yml
-rwxr-xr-x 1 root root 331 element.yml
-rwxr-xr-x 1 root root 355 excalidraw.yml
-rwxr-xr-x 1 root root 427 filegator.yml
-rwxr-xr-x 1 root root 530 firefox.yml
-rwxr-xr-x 1 root root 417 forgejo.yml
-rwxr-xr-x 1 root root 350 fossil.yml
-rwxr-xr-x 1 root root 734 frigate.yml
-rwxr-xr-x 1 root root 358 gitea.yml
-rwxr-xr-x 1 root root 723 gitlab.yml
-rwxr-xr-x 1 root root 680 goaway.yml
-rwxr-xr-x 1 root root 409 grafana.yml
-rwxr-xr-x 1 root root 753 hedgedoc.yml
-rwxr-xr-x 1 root root 458 home-assistant.yml
-rwxr-xr-x 1 root root 1284 immich.yml
-rwxr-xr-x 1 root root 383 influxdb.yml
-rwxr-xr-x 1 root root 402 jackett.yml
-rwxr-xr-x 1 root root 526 jellyfin.yml
-rwxr-xr-x 1 root root 920 kimai.yml
-rwxr-xr-x 1 root root 4281 librenms.yml
-rwxr-xr-x 1 root root 374 librespeed.yml
-rwxr-xr-x 1 root root 425 lidarr.yml
-rwxr-xr-x 1 root root 1025 mediamanager.yml
-rwxr-xr-x 1 root root 399 memos.yml
-rwxr-xr-x 1 root root 470 minio.yml
-rwxr-xr-x 1 root root 596 mosquitto.yml
-rwxr-xr-x 1 root root 444 n8n.yml
-rwxr-xr-x 1 root root 2720 netbox.yml
-rwxr-xr-x 1 root root 1377 nextcloud.yml
-rwxr-xr-x 1 root root 298 nocodb.yml
-rwxr-xr-x 1 root root 286 nodered.yml
-rwxr-xr-x 1 root root 408 ntfy.yml
-rwxr-xr-x 1 root root 398 nzbget.yml
-rwxr-xr-x 1 root root 436 openwebrx.yml
-rwxr-xr-x 1 root root 368 openwebui.yml
-rwxr-xr-x 1 root root 806 partdb.yml
-rwxr-xr-x 1 root root 1090 pihole.yml
-rwxr-xr-x 1 root root 661 plex.yml
-rwxr-xr-x 1 root root 10438 pmacct-netflow.yml
-rwxr-xr-x 1 root root 696 prowlarr.yml
-rwxr-xr-x 1 root root 687 rabbitmq.yml
-rwxr-xr-x 1 root root 424 radarr.yml
-rwxr-xr-x 1 root root 252 redlib.yml
-rwxr-xr-x 1 root root 546 restic-server.yml
-rwxr-xr-x 1 root root 2039 roundcube.yml
-rwxr-xr-x 1 root root 645 searxng.yml
-rwxr-xr-x 1 root root 549 smokeping.yml
-rwxr-xr-x 1 root root 2893 snipeit.yml
-rwxr-xr-x 1 root root 284 solr.yml
-rwxr-xr-x 1 root root 429 sonarr.yml
-rwxr-xr-x 1 root root 498 sonatype-nexus.yml
-rwxr-xr-x 1 root root 373 speedketchup.yml
-rwxr-xr-x 1 root root 625 syncthing.yml
-rwxr-xr-x 1 root root 532 technitium.yml
-rwxr-xr-x 1 root root 442 transmission.yml
-rwxr-xr-x 1 root root 398 upsnap.yml
-rwxr-xr-x 1 root root 322 uptime-kuma.yml
-rwxr-xr-x 1 root root 423 urbackup-client.yml
-rwxr-xr-x 1 root root 452 urbackup-server.yml
-rwxr-xr-x 1 root root 357 vaultwarden.yml
-rwxr-xr-x 1 root root 459 victoria-logs.yml
-rwxr-xr-x 1 root root 343 victoria-metrics.yml
-rwxr-xr-x 1 root root 696 viseron.yml
-rwxr-xr-x 1 root root 458 wallabag.yml
-rwxr-xr-x 1 root root 1201 warracker.yml
-rwxr-xr-x 1 root root 441 webtop.yml
-rwxr-xr-x 1 root root 764 wordpress.yml
-rwxr-xr-x 1 root root 1878 zabbix.yml
The following media drivers have been added.
/lib/modules/5.6.3-64/kernel/drivers:
total 8
drwxr-xr-x 5 root root 4096 media
drwxr-xr-x 3 root root 4096 staging
/lib/modules/5.6.3-64/kernel/drivers/media:
total 12
drwxr-xr-x 3 root root 4096 common
drwxr-xr-x 3 root root 4096 usb
drwxr-xr-x 2 root root 4096 v4l2-core
/lib/modules/5.6.3-64/kernel/drivers/media/common:
total 4
drwxr-xr-x 2 root root 4096 videobuf2
/lib/modules/5.6.3-64/kernel/drivers/media/common/videobuf2:
total 88
-rw-r--r-- 1 root root 42576 videobuf2-common.ko
-rw-r--r-- 1 root root 4584 videobuf2-memops.ko
-rw-r--r-- 1 root root 23176 videobuf2-v4l2.ko
-rw-r--r-- 1 root root 9176 videobuf2-vmalloc.ko
/lib/modules/5.6.3-64/kernel/drivers/media/usb:
total 4
drwxr-xr-x 2 root root 4096 uvc
/lib/modules/5.6.3-64/kernel/drivers/media/usb/uvc:
total 100
-rw-r--r-- 1 root root 101376 uvcvideo.ko
/lib/modules/5.6.3-64/kernel/drivers/media/v4l2-core:
total 268
-rw-r--r-- 1 root root 28136 v4l2-dv-timings.ko
-rw-r--r-- 1 root root 244872 videodev.ko
The following net drivers have been added.
/lib/modules/5.6.3-64/kernel/net:
total 16
drwxr-xr-x 3 root root 4096 ipv4
drwxr-xr-x 3 root root 4096 ipv6
drwxr-xr-x 4 root root 4096 netfilter
drwxr-xr-x 2 root root 4096 sctp
/lib/modules/5.6.3-64/kernel/net/ipv4:
total 4
drwxr-xr-x 2 root root 4096 netfilter
/lib/modules/5.6.3-64/kernel/net/ipv4/netfilter:
total 16
-rw-r--r-- 1 root root 4208 nf_socket_ipv4.ko
-rw-r--r-- 1 root root 5280 nf_tproxy_ipv4.ko
/lib/modules/5.6.3-64/kernel/net/ipv6:
total 4
drwxr-xr-x 2 root root 4096 netfilter
/lib/modules/5.6.3-64/kernel/net/ipv6/netfilter:
total 12
-rw-r--r-- 1 root root 3768 nf_socket_ipv6.ko
-rw-r--r-- 1 root root 5496 nf_tproxy_ipv6.ko
/lib/modules/5.6.3-64/kernel/net/netfilter:
total 440
drwxr-xr-x 2 root root 4096 ipset
drwxr-xr-x 2 root root 4096 ipvs
-rw-r--r-- 1 root root 12984 nf_conncount.ko
-rw-r--r-- 1 root root 4008 nf_dup_netdev.ko
-rw-r--r-- 1 root root 17968 nf_synproxy_core.ko
-rw-r--r-- 1 root root 133128 nf_tables.ko
-rw-r--r-- 1 root root 30080 nf_tables_set.ko
-rw-r--r-- 1 root root 8112 nfnetlink_osf.ko
-rw-r--r-- 1 root root 5152 nft_chain_nat.ko
-rw-r--r-- 1 root root 11120 nft_compat.ko
-rw-r--r-- 1 root root 6168 nft_connlimit.ko
-rw-r--r-- 1 root root 6768 nft_counter.ko
-rw-r--r-- 1 root root 15712 nft_ct.ko
-rw-r--r-- 1 root root 4520 nft_dup_netdev.ko
-rw-r--r-- 1 root root 5952 nft_fwd_netdev.ko
-rw-r--r-- 1 root root 6680 nft_hash.ko
-rw-r--r-- 1 root root 6624 nft_limit.ko
-rw-r--r-- 1 root root 5528 nft_log.ko
-rw-r--r-- 1 root root 7272 nft_masq.ko
-rw-r--r-- 1 root root 6608 nft_nat.ko
-rw-r--r-- 1 root root 6144 nft_numgen.ko
-rw-r--r-- 1 root root 5848 nft_objref.ko
-rw-r--r-- 1 root root 5296 nft_osf.ko
-rw-r--r-- 1 root root 5760 nft_quota.ko
-rw-r--r-- 1 root root 6928 nft_redir.ko
-rw-r--r-- 1 root root 4792 nft_reject.ko
-rw-r--r-- 1 root root 4920 nft_reject_inet.ko
-rw-r--r-- 1 root root 5192 nft_socket.ko
-rw-r--r-- 1 root root 7240 nft_synproxy.ko
-rw-r--r-- 1 root root 6936 nft_tproxy.ko
-rw-r--r-- 1 root root 8968 nft_tunnel.ko
-rw-r--r-- 1 root root 5768 nft_xfrm.ko
-rw-r--r-- 1 root root 3408 xt_comment.ko
-rw-r--r-- 1 root root 5304 xt_ipvs.ko
/lib/modules/5.6.3-64/kernel/net/netfilter/ipset:
total 428
-rw-r--r-- 1 root root 38784 ip_set.ko
-rw-r--r-- 1 root root 10720 ip_set_bitmap_ip.ko
-rw-r--r-- 1 root root 10576 ip_set_bitmap_ipmac.ko
-rw-r--r-- 1 root root 10088 ip_set_bitmap_port.ko
-rw-r--r-- 1 root root 24912 ip_set_hash_ip.ko
-rw-r--r-- 1 root root 24496 ip_set_hash_ipmac.ko
-rw-r--r-- 1 root root 24536 ip_set_hash_ipmark.ko
-rw-r--r-- 1 root root 25408 ip_set_hash_ipport.ko
-rw-r--r-- 1 root root 25840 ip_set_hash_ipportip.ko
-rw-r--r-- 1 root root 30008 ip_set_hash_ipportnet.ko
-rw-r--r-- 1 root root 16456 ip_set_hash_mac.ko
-rw-r--r-- 1 root root 27744 ip_set_hash_net.ko
-rw-r--r-- 1 root root 29616 ip_set_hash_netiface.ko
-rw-r--r-- 1 root root 29728 ip_set_hash_netnet.ko
-rw-r--r-- 1 root root 29344 ip_set_hash_netport.ko
-rw-r--r-- 1 root root 30800 ip_set_hash_netportnet.ko
-rw-r--r-- 1 root root 11304 ip_set_list_set.ko
/lib/modules/5.6.3-64/kernel/net/netfilter/ipvs:
total 244
-rw-r--r-- 1 root root 144704 ip_vs.ko
-rw-r--r-- 1 root root 4544 ip_vs_dh.ko
-rw-r--r-- 1 root root 3656 ip_vs_fo.ko
-rw-r--r-- 1 root root 9152 ip_vs_ftp.ko
-rw-r--r-- 1 root root 8000 ip_vs_lblc.ko
-rw-r--r-- 1 root root 9056 ip_vs_lblcr.ko
-rw-r--r-- 1 root root 3656 ip_vs_lc.ko
-rw-r--r-- 1 root root 6248 ip_vs_mh.ko
-rw-r--r-- 1 root root 3720 ip_vs_nq.ko
-rw-r--r-- 1 root root 3656 ip_vs_ovf.ko
-rw-r--r-- 1 root root 5648 ip_vs_pe_sip.ko
-rw-r--r-- 1 root root 4032 ip_vs_rr.ko
-rw-r--r-- 1 root root 3720 ip_vs_sed.ko
-rw-r--r-- 1 root root 4952 ip_vs_sh.ko
-rw-r--r-- 1 root root 3720 ip_vs_wlc.ko
-rw-r--r-- 1 root root 4736 ip_vs_wrr.ko
/lib/modules/5.6.3-64/kernel/net/sctp:
total 308
-rw-r--r-- 1 root root 313168 sctp.ko
It's been almost two years since I complained about iptables -j MARK not working in containers (SUP-138792). I still doubt whether this set of net drivers is enough for Tailscale containers to work properly.
After upgrading my RB4011 (Wi-Fi model) to RouterOS 7.21 Beta 2, I noticed that my devices take slightly longer to receive an IP address from the DHCP server compared to version 7.20.
My setup includes:
-
RB4011 as the main router (bridge with IPv4 + IPv6)
-
One hAP ax² connected as an access point
-
DHCP server on the bridge interface
The delay happens during initial IP assignment — both wired and wireless clients experience it. Once the IP is assigned, everything works normally.
I’ve checked bridge hardware offload and DHCP configuration, and everything seems correct. This behavior started only after upgrading to 7.21 Beta 2.
Is this a known issue related to the bridge or DHCP changes introduced in this version (e.g., Option 82 improvements)?
Thank you for your time,
1 Like
No, definitely it is not a known issue. And I do not think your observed issue is even related to what BrateloSlava reported.
Can you make the "longer to receive an IP address" reproducible? Is it really related to 7.21? How much longer? What happens with DHCP packets on RB4011 and hAP ax² (e.g. /tool/sniffer/quick port=bootpc)? Does the DHCP clients directly connected to RB4011 Ethernet experience the same issue, or is it only through wifi? Does disabling bridge HW offload on RB4011 make any difference?
If you believe that problem is introduced in this version, please share supout.rif files from both of your devices and send it to support@mikrotik.com.
There is also a list of apps in the docs already: Containerized App management - RouterOS - MikroTik Documentation
I only noticed it in version 7.21, in version 7.20 normal!
#[SUP-201158]: Delay happens during initial IP assignment bridge 7.21Beta2
1 Like
So this has been here before but then it was no for current platforms so will this work with wifi-qcom??
A new version and unfortunately the possibility of implementing 6VPE over IPv4 infrastructure is still not implemented 
.
2 Likes
container - added "/app" menu for simple containerized app installation (requires "container" package);
The veth interface that is automatically created on the bridge has a pre-assigned PVID.
A PVID field should be added in per-app settings that allows the user to override it, so that the virtual interface can be correctly VLAN-tagged.
1 Like
My ax3 also has ether5 not working properly with 7.21beta2. If I connect the device to a different port and then return it to ether5, it starts working, but after a reboot, the ax5 ether5 breaks again. It doesn't matter whether the device's IP is configured statically or if it's trying to get an address via DHCP. “/interface/bridge/host/print where on-interface=ether5” doesn't show any devices, although “/interface/ethernet/monitor ether5” shows everything fine, and even “/interface/print stats where name=ether5” shows non-zero counters on the RX and TX.
No need to add “my niche use-case still has not been implemented” to a release topic! What has been implemented is listed in the changes.
No IPsec VTI either. Probably a lot more users are waiting for that.
3 Likes
This functionality seems to work now with the following syntax (It assigns prefix based on the address pool created via DHCPv6 client), however after an hour or so the addresses show as Global and deprecated. Is anyone else seeing this behavior?
/ipv6 address
add address=::1 from-pool=ezee_pool interface=trusted_lan
add address=::2:0:0:0:1 from-pool=ezee_pool interface=dmz
add address=::1:0:0:0:1 from-pool=ezee_pool interface=guest_wifi
add address=::3:0:0:0:1 from-pool=ezee_pool interface=remoteaccess_vpn
Flags: X - disabled, I - invalid; D - dynamic
0 D prefix=my:ipv6:prefix:0::/64 6to4-interface=none interface=trusted_lan on-link=yes autonomous=yes
valid-lifetime=6d23h47m7s preferred-lifetime=47m7s
1 D prefix=my:ipv6:prefix:2::/64 6to4-interface=none interface=dmz on-link=yes autonomous=yes valid-lifetime=6d23h47m7s
preferred-lifetime=47m7s
2 D prefix=my:ipv6:prefix:1::/64 6to4-interface=none interface=guest_wifi on-link=yes autonomous=yes valid-lifetime=6d23h47m7s
preferred-lifetime=47m7s
3 D prefix=my:ipv6:prefix:3::/64 6to4-interface=none interface=remoteaccess_vpn on-link=yes autonomous=yes
valid-lifetime=6d23h47m7s preferred-lifetime=47m7s
Flags: D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL; d - DEPRECATED
Columns: ADDRESS, FROM-POOL, INTERFACE, VRF, ADVERTISE, VALID
# ADDRESS FROM-POOL INTERFACE VRF ADVERTISE VALID
0 Gd my:ipv6:prefix:0::1/64 ezee_pool trusted_lan main yes 6d9h54m55s
1 Gd my:ipv6:prefix:2::1/64 ezee_pool dmz main yes 6d9h54m55s
2 Gd my:ipv6:prefix:1::1/64 ezee_pool guest_wifi main yes 6d9h54m55s
3 Gd my:ipv6:prefix:3::1/64 ezee_pool remoteaccess_vpn main yes 6d9h54m55s
Does BOPOHA's response seem familiar to the problem I reported?
