On this version I’m not getting any ARP responses from other routers within my Zerotier network. Downgrade to 7.16.2, same config works again. I also tried 7.18beta6, have the same problem. Full details of my issue, including the most minimal test config possible, are here: http://forum.mikrotik.com/t/zerotier-struggles-on-v7-17/181819/4
EDIT: The issue for me specifically appears to be related to this part of my Flow Rules, which was from a default example provided by Zerotier:
tag server
id 2
enum 0 No
enum 1 Yes
default No;
# if both members are not servers, break
break not tor server 1;
If I comment out the break then things work as expected. 172.23.0.1 is a non-Mikrotik Zerotier node running 1.14.2, and it has the server tag set to 1. This means that the traffic should be allowed to/from that IP by the rest of the Zerotier network.
After rolling back all the way to 7.14.3 I’ve found the solution, remove the discovery interface and use the IP of the respective controller like this:
/interface wifi cap
set caps-man-addresses=
I only got on error like this from only one device:
disconnecting from @, activity timeout (instead of connection interrupted)
I’ll attempt to upgrade to the next latest stable version when it’s released, maybe this error is just a bug from a RouterOS version from April 2024.
I would kindly ask Mikrotik to update the documentation when mixed Capsman environments are used. The use of the discovery interface when Capsman and Wifi Capsman are used on the same L2 domain on separate controllers is not recommended, the best way is to use caps-man-addresses.
SSTP VPN problem on 7.17+
After upgrading RB3011 to 7.17.2, SSTP works for a while and then all VPN clients disconnect. No one can reconnect until the router restarts, I went back to 7.16.2
I have a DNS resolver question: is it to be expected that Mikrotik DNS cache can contain 2 different entries for a) the same name and b) same type?
/ip/dns/cache print where name="foo.example.com"
Columns: NAME, TYPE, DATA, TTL
# NAME TYPE DATA TTL
48 foo.example.com CNAME www.example.com. 3h52m38s
398 foo.example.com CNAME example.com.cdn.cloudflare.net. 4m7s
I guess the answer is: yes, perfectly valid. But I am asking because in this case it happened, that DNS cache was somehow bypassed (“resolvectl query foo.example.com --cache=no”) took very long and were - verified - sent to upstream DoH resolver. Instead of serving from cache.
The above DNS content is invalid. You cannot have two CNAME records for the same DNS name!
But just like many DNS servers will not enforce that or will only issue a warning (and similar for web-based DNS editors), most DNS resolvers will not check for upstream errors and will just cache whatever garbage they are presented.
But yes, the cache can contain multiple entries for the same type as that (except for CNAME) is usually allowed.
*) dhcpv6-client/server - added support for DHCPv6 reconfigure messages;
Regarding the “allow-reconfigure” property added to “/ipv6 dhcp-client” that is set to “no” by default:
I feel tempted to set it to “yes”. Are there any good reasons not to do so?
If the DHCPv6 Server from my ISP sends a reconfigure message, I suppose it must have a valid (and important) reason to do so (perhaps it could be that some internal maintenance happened and the previous lease I had is not valid anymore?). I have no security concerns, since I have a PPPoE Client connection and the IPv6 firewall only allows UDP packets with destination port 546 coming from link-local addresses (so, that pretty much guarantees that the DHCPv6 messages are coming from my ISP).
I had this issue also on a Hex - hard reboot does nothing as any config changes are lost so you cant even uninstall a package etc. I did a backup to flash card (although it also allowed me to put this in root so methinks its just misreporting)
hard reset device and then restored.
upon restore I watched the free space - was on about 900KiB - this went down every now and then but recovered, didnt take 30 minutes and device was in same state - seems like if it gets itself down to 0 it doesnt free anything to recover. followed process again, and this time uninstalled wireless package straight away (I use this device to manage capsman for a network) - after that ended up with 2500KiB free space and although its still wildly fluctuating down to 1500 or so sometimes it seems stable.
I also run the dude on this device using the flash card but the dude package is 1300 by itself so can junk that if I really have to, just wish I knew where the space is being used up and then freed up continually
Bug report (second time): The serial-based console on the CCR2216 will find itself stuck in used/non-free mode after a while, even when there are no active connections. The only way to restore it is to disable it then enable it via the web interface (since the console is unavailable via serial). This problem was introduced with 7.17.
The pics above show 1) when the problem occurs 2) immediately after the console is disabled/enabled 3) slightly later when things get back to normal. With the 2nd pic, we’re not sure why the console shows both “used” and “free” at the same time, but somehow it does.
For the record, we have a node that connects to the router via serial to collect some key KPIs every 5 minutes, we get notifications from that node if the switch is unreachable, and that’s how we know. It does take several days for the problem to show up, it’s not instantaneous and appears to happen randomly. Last time the problem happened, we disconnected the serial interface and tried to reconnect via another computer, to weed out the possibility that the computer connecting to the router was the problem–the problem was still there.
Are the following openssh vulnerabilities a problem for RouterOS v7.17.2?
CVE-2025-26465: MitM attack against OpenSSH’s VerifyHostKeyDNS-enabled client
CVE-2025-26466: DoS attack against OpenSSH’s client and server
It’s been said that ssh in ROS is not based on OpenSSH. So in theory those vulnerabilities are not present in ROS. In practice they might or might not be …
after update RB952Ui-5ac2nD 7.15 > 7.17.2 ports are not working, wifi too
i cant access to router, even with netinstall (because ports are not working)
Most likely the RB952Ui-5ac2nD died due to lack of storage during the upgrade. But netinstall should work.
I had to netinstall a CCR1009 and ran into an issue because apparently the bootloader had been set to “flash-boot” and would not netinstall. I think it is due to a change in 7.16 firmware.
In that case I could netinstall it by entering Ctrl-E on the serial port to defeat that. Would not know how to do that on a lite device.
Failed upgrade of ROS doesn’t affect ability to run netinstall by itself. Failed routerboard upgrade could … but for this reason there’s backup routerboot which can be invoked by pressing button during powering up the device. Backup routerboot is also able to initiate netinstall process … The “non working ports” problem could well be result of a boot loop or something like that … which (again) isn’t affected by failed ROS upgrade.
As well: netinstall is pretty fragile process and even on perfectly working device it might take a few tries before it starts to work (communication between device and management PC).
It seems that in 7.16 there have been changes in the firmware to allow devices to return to factory state when a reset-configuration is done (either using command or the button) and it apparently sometimes gets invoked incorrectly, blocking a netinstall.
If the service is not acessible to the bad guys, there’s no vulnerability!