V7.23rc [testing] is released!

That explanation actually matches the observed behavior pretty well.

What made me think something changed in 7.23 is that on older versions the adapter was not usable at all, while now on ARM64:

  • the interface is created correctly

  • the USB device is identified properly

  • traffic passes normally

  • throughput can reach nearly 2Gbps (with a bit of CPU bottleneck on core0)

So the data path itself is clearly functional.

The remaining problems seem limited to driver/link-state handling:

  • missing negotiated rate/duplex information

  • auto-negotiation shown as incomplete

  • incorrect carrier/link-state propagation

Which is exactly why I reported it during RC testing. It looks less like “completely unsupported hardware” and more like “partially working driver with missing features”.

Three weeks from report to fix. I am impressed.

SUP-215939 - RouterOS doesn't send IPv6 Solicited Neighbor Advertisements on receipt of Neighbor Solicitations. Specifically, the solicitation is being sent to a solicited-node multicast address.

2026-05-08 10:02:48 bridge,warning no buffer space available for fdb notify
wat dis
RB5009 - 7.23rc3, have not seen this before.

Last version without problem for my setup 7.19.6
7.20.8, 7.21.4, 7.22.2
I have the same message as you
on 4pcs Chateau5G
bridge,warning no buffer space available for fdb notify

I've seen this in earlier versions already.

Still getting DoH errors in Log i thought 7.23 was supposed to fix these DoH issues with HTTP/2 support.
Support ticket said so, sent my Supout.rif to them and they suggested 7.23 upgrade.
SUP-214073.

This is caused by something different and has nothing to do with HTTP/2 support, AFAIK.

Have you tried a different DoH server? What server are you currently using?

    1. l3hw - added HW offloaded VRF support on CRS8xx switches;
    2. l3hw - added VRF assignment via switch ACL rules on CRS8xx switches (CLI only);

How may we configure it? Cannot find any documentation at help.mikrotik.com Could you please provide an example configuration?

Splited topic for Mozerd's problem: Problem with DHCP in 7.23rc when used behind Rogers' modem in Canada If any post missed then let me know.

My power went out a few times today due to scheduled maintenance. For some reason, one of my new DHCP addresses was lost. After restoring it to the automatic backup that runs every 24 hours, the address didn't return from the configuration file.

[SUP-216309]

  1. The DYNAMIC address:

    • Will not be saved on persistent configuration (config.db).
    • Will not be saved on a "/export terse show-sensitive file=export.rsc".
    • Will not be saved on a backup file.
  2. So your expectations are not aligned with how the protocol works.

  3. The only one correct way of having a really persistent DHCP supplied address is if you Service provider create an static reservation for your contracted link. But usually this is made through a via monthly fee for that.

  4. If you know what you are doing, you could (I do not recommend it.) add a custom option on the dhcp-client telling to DCHP that you already have your IP. But if it works, means your service provider did not its homework protecting from that.

  5. The only place where you IP Address could be persisted is on a support.rif.
    But it does not solve you problem. Right?

  6. Considering your reaction demonstrating serious concern, including opening a support ticket, I imagine you must have published internal services through the IP address.

    • If that is indeed the case:
      • This is not a recommended methodology!
      • I suggest you use Mikrotik's own dynamic DNS service available at "/ip/cloud/".
      • Depending on the type of service you are publishing (basically http/https), using a reverse proxy can also be very helpful.

P.S.: This is another topic that shouldn't be in a new release announcement thread. I suggest you open a separate thread in the forum specifically for this.

image

Oh...
So the actual issue is: "One of my DHCP client's lease (for which I did not set a static lease but purely rely on store-leases-disk=whatever(except never) option to work properly during a few power outages) got changed".
Have I got it right?

I will try to create on this thread the opportunity of leave non-related-to-topic behind and talk directly about what I believe being on-topic questions.
I will start asking directly to @MikrotikTeam about several topics that I believe being related to a Release-Candidate, and also other.
I hope this catalyze other good questions.

Here are my initial shots...

On the control-plane side of routing itself:

101. Support to TWAMP to feed the Traffic Engineering TLVs of IS-IS or OSPF.
102. Support to Fast Reroute (FRR), at least basic support to IPv4/IPv6. Labels would be great!
103. TE for ISIS based networks. It already works?
104. Auto-cost reference-bandwidth for OSPF and IS-IS. Any chance? Any ETA?
104. Really functional L3VPN (vpnv6/vpnv4). No blablabla of "you need enable LDPv6 on all your backbone". Considering historic issues, it is solved? I will summon @oreggin on this one.
105. EVPN handling MPLS as transport protocol, and nvGRE if it comes.
106. BGP-LU. Is that dreaming too big?
107. Support to BMP - BGP Monitoring Protocol.

On the dataplane-plane side:

201. VRF Hardware-Offload, has already been born on CRS8XX. And what about the rest of the products with switchchips. Any ETA?
202. MPLS Hardware-Offload. VXLAN is done. But what about MPLS?
203. CCRs 2004 with its pseudo-switchchips (used as PIPEs) can be considered out of range of Hardware-Offload?
204. L2VPN at least has fastpath, what about L3VPN support to fastpath?
205. Several recent moves smelling good on the aspect of Routing-Rules. Anything coming soon? Flowspec?
206. Hardware-Offload of GRE and adding support to nvGRE. Possible? The HW-OL for GRE seams to be the most feasible of all mentioned. All the Prestera support it, and without doing any search I bet to say that all the other switch chips used in devices that are no in "archive" o products list also supports GRE HW-OL.
207. SRv6 is for sure dreaming too big... Not before RouterOS V9
208. Support to sflow, with minimum extra work to Control-Plane when sampled by SwitchChip. Not Needing to disable Hardware-Offload when you need some kind of flow sampling.

On others aspects:

301. Circuit-ID/Remote-ID, Option82, PPPoe+, TR-101. Customizable RAIO, Appendable RAIO, will be available? String instead of hex, is it possible?
302. Possibility to use global variables on Routing Filters. Any chance?
303. Possibility to trigger an script during the processing of a route on routing filters. Any chance?
304. ISIS on Winbox? When?
305. Bridge with Vlan filtering and ingress filtering enabled by default. Could it happen? Maybe depending on device-mode... Admit-all is always a stab in the back!
306. Real QinQ, real tag stacking(not that placebo of blind tag stacking), Selective QinQ, hybrid port, and all related to that. It's been a long time since the last moves on this.
307. Some kind of "/system routerboard supported-features print" that list of all features that may or may not be supported, and obvious the information if that devices supports, do not support, or support under specific circumstances.

Thanks for the drivers.

In most cases, the audio device is somehow occupied by the system and can't be added to the container.
To test functionality, I had to connect several audio devices via a USB hub, and then only one was available.
Roon Bridge works with USB audio cards in the container, everything is great!

Please fix the unavailability of connected audio devices in the system.

After rebooting the router, the problem has not yet been reproduced.

If I might add one thing: hardware pppoe would be nice .. Gigabit pppoe tends to overload even the ccr2116 ...

I partially agree!
The point against is that MikroTik do not have any hardware with SwitchChips with the kind of chips that supports that kind of feature.

For example, that kind of hardware offload you will only see in SwitchChips of Broadcom in the family StrataDNX (Qunran, Jericho). Or in Chips like Intel Tofino(an ASIC that is almost a FPGA, but is already discontinued).

So, we need to keep the expectations inside the reality.
The SwitchChip has the feature declared as supported in Datasheet? So, It depends on the NOS vendor (MikroTik in our case) to program correctly the Switchchip.

Edit 1: A clear example of this in MikroTik World?
All Marvell Prestera supports Selective QinQ in hardware.
But by the way MikroTik deals with Vlans, they can't use Selective QinQ already native on the chips they already use.

Edit 2: I get frustrated when I see that MikroTik's users demands are focused on complements, embellishments, and fru-frus for what will come in the Alpha, Beta, and RC versions.
While the demands should really be focused on these basic concepts of routing performance.

What's new in 7.23rc4 (2026-May-22 10:53):

  • app - added "network-outgoing-access=yes/no" setting to prevent containers from initiating outbound traffic;
  • bridge - fixed dynamic VLAN update for WiFi interfaces;
  • bridge - improved MAC synchronization for MLAG (additional fixes);
  • certificate - improved ACME logging (additional fixes);
  • certificate - improved ACME status reporting (additional fixes);
  • cloud - cloud backup file management now requires "policy" policy;
  • container - updated /dev/net/tun permission;
  • crypto - fixed stability issue;
  • dhcpv4-server - added "add-dns-entries" and "add-dns-entries-suffix" properties for creating local DNS entries (additional fixes);
  • discovery - added "add-dns-entries" and "add-dns-entries-suffix" properties for creating local DNS entries (additional fixes);
  • firewall - added "action=drop" to mangle;
  • firewall - matcher "in-bridge-port" does not require "use-ip-firewall=yes";
  • ike2 - fixed child SA cleanup during flush operation;
  • ike2 - fixed pending responder connection cleanup after peer removal;
  • ike2 - fixed SA delete handling on initiator during rekey;
  • ike2 - improved HMAC size validation checks;
  • iot - fixed LoRa lockpack preventing lock from applying;
  • ipv6,ra - improved service stability (additional fixes);
  • isis - allow to configure metric-type;
  • leds - fixed power LED turning off while LTE interface is inactive (introduced in v7.22);
  • lte - fixed rare cases where the Tx queue could stop and never wake up on multi-core CPU devices;
  • switch - fixed issue with MAC table for RB2011 (introduced in v7.21);
  • switch - fixed missing ethernet counters for non-running interfaces on CRS8xx switches (introduced in v7.22);
  • system - improved switching to HTTP/1 if HTTP/2 is not supported by remote host (additional fixes);
  • timezone - updated timezone information from "tzdata2026b" release;
  • vrrp - fixed stability issue when using VRRP with a hardware-offloaded bridge (additional fixes);
  • vxlan - fixed fast-path when using "checksum=no" (introduced in v7.20);
  • wifi - improved on-capsman traffic processing;
  • www - improved REST API user cache processing;
  • www - properly respond with custom HTTP response code instead of replying always with 200 (introduced in v7.23rc1);

This fixes SUP-215924. I guess this bug affected dynamic lte interfaces connected via USB.