7.23.7 [long-term] is released!

Announcements
88

I'm seeing a possible regression with container networking after upgrading to RouterOS 7.23.7 and I'm wondering if anyone else is experiencing the same issue.

I have a container connected to a VLAN with a RouterOS DHCP server.

After upgrading to RouterOS 7.23.7:

  • The container successfully gets an IP address from the DHCP server.
  • The IP address, gateway, and DNS settings are received correctly.
  • However, the container has no network connectivity afterward.
  • The same setup was working correctly before the RouterOS upgrade.
  • If I configure a static IP from the same VLAN/subnet, the container has connectivity normally.

So the VLAN, bridge, routing, and container networking appear to work when using a static address. The problem only occurs when the container obtains its configuration through DHCP.

Relevant configuration

# RouterOS 7.23.7

/interface veth
add container-mac-address=0A:D7:9B:1A:8F:40 \
    dhcp=yes \
    mac-address=0A:D7:9B:1A:8F:3F \
    name=veth1

/interface bridge port
add bridge=bridge1 interface=veth1 pvid=100

/ip dhcp-server
add add-arp=yes address-pool=pool100 always-broadcast=yes \
    interface=vlan100 name=dhcp100 use-reconfigure=yes

/ip dhcp-server network
add address=10.100.0.0/24 \
    dns-server=10.100.0.1 \
    gateway=10.100.0.1 \
    ntp-server=194.146.239.1

/ip address
add address=10.100.0.1/24 \
    interface=vlan100 \
    network=10.100.0.0

The container receives an address in the 10.100.0.0/24 subnet from DHCP, but cannot communicate with the network afterward.

For comparison, configuring the container with a static IP from the same 10.100.0.0/24 subnet works normally.

Has anyone else encountered this on RouterOS 7.23.7, specifically with containers/VETH interfaces using DHCP?

I'm particularly interested in knowing whether this is a known regression in 7.23.7 or if there is some additional configuration required for DHCP-assigned container interfaces.

89

Upgrading from LTS 7.23.5 to 7.23.7 broke Romon connectivity to CRS112 and CRS210 Switches. CRS328-24P was OK. I can also access all CAP AC and CAP AX AP's.

Subsequent upgrading to 7.24.4 did not fix the issue.

Downgrading back to 7.23.5 did not fix it either.

Prior to the update all devices were accessible.

90

If downgrade didn't fix the issue than it probably isn't the RouterOS release issue.
You should check RoMON config, did you set the secret or ID, are those switches visible in RoMON discovery from say CRS328-24P...

91

What's wrong with my DNS? No problems before today.

Solved.

92

deleted too

93

deleted

94
96

@dvm If it's still unclear to you: the list of dns servers includes both those you specified manually plus the dynamic ones.

It's quite clear that (at least one of) your dynamic servers started returning SERVFAIL resposes.

You should probably disable these via the use-peer-dns setting on your dhcp/pppoe client.

98

/ip/dns/cache/flush

99

Any recent firewall changes that might be eating the traffic? Ping works, so the path is routing, butnhow about the port?

102

OK, used manually . . . . From on the router directly (I don't recall ever seeing that work in your posts) or a connected client?

103

Already tried reboot? Also probably resolve tries ipv6 dns as well. Check that also.

106

Well, if nothing else is left... post full export, log the packets in fw, capture the packets and dissect them ... In a dedicated thread.

107

New SSL.com certificate is required.
use-doh-server=no is my stupid mistake (must be use-doh-server=""), sorry.

108

Here is where the issue is on an MIPSBE device - System Id getting corrupted :

[admin@R0001] /system/identity> set name="R0001"
[admin@R0001] /system/identity> pr
name: R
0
0
0
1
[admin@R0001] /system/identity>

Also evident on new hAP be Lite which is arm.....

[admin@hAP] /system/identity> pr
name: h
A
P
[admin@hAP] /system/identity>

And ARM64 RB5009:

[admin@Classroom v7 ] /system/identity> pr
name: C
l
a
s
s
r
o
o
m

    v
    7

[admin@Classroom v7 ] /system/identity>

And OK on cAP Ax running RoS7.23.3 :slight_smile:

[admin@Workshop] /system/identity> pr
name: Workshop
[admin@Workshop] /system/identity>

109

Does anybody use tr69 protocol to manage mikrotiks? We are seeing increased connection problems on versions 6.23.7 and 6.24.4. Namely in some cases the connection request (CR) issued by the ACS will get straight away RST, ACK from Mikrotiks. Problem seems (not confirmed) to arise when more CR are sent than usual - for example in cases when device is viewed or some action is done. The problem goes away after mikrotik tr69 client is disabled/enabled. Until that the device can not be managed with ACS as it is blocking the CR.

Has anyone experienced this issue? I see that in development channel version 7.25beta3 there is "tr069 - improve stability". Tested it in minimal scale and it seems to improve that situation. Has anyone reported this and Mikrotik responded? Seems like a DOS protection what is too eager.

For additional information - comparing TR69 connection request flow between v6 and v7 ROS I see that v6 version Mikrotiks end the CR conversation with FIN,ACK but in v7 the connection is not teared down. Has anyone noticed that? If it is a DOS protection feature this could intensify the RST problem although flushing manually the connection table is not improving the problem only tr69 service restart.

111

This defect is present in 7.23.7, 7.24.4 and 7.25 beta5. Mikrotik support stated that "it will be fixed in future versions".

112

no fix for CVE-2026-84411 on LTS?

113

There is no S (support) in MikroTik designation, just LT (long-term) meaning they will mostly leave it unchanged for some time.
So I suppose we would have to wait for 7.25 to became [stable] which will automagically and effortlessly make 7.24 [long-term] to get the fix...

114

FWIW, just direct updated a spare haP lite to 7.23.7 from 7.21.2, iirc. No issues, and still has plenty of both ram and nand . . . (now back to the shelf . . . )