I think the reason this has a high probability of appearing at reboot is because while the router is being rebooted, clients in the network are still firing DNS queries at it (everything requires address resolution and TTL are nowadays quite short). Normally the queries are made with UDP and are not affected by the TCP SYN flood detection. But because the router can’t answer while being rebooted and the timeout for UDP DNS queries is very short, I think 1-5 seconds depending on the OS (Windows starts with one second https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-client-resolution-timeouts), the clients will quickly retries a couple of times. After that, they normally switch to TCP 53 and issue the queries again, also with shorter timeout than other normal TCP connections (because DNS shouldn’t hold back everything else for too long). If the router comes back online during this period, it sees a lot of simultaneous TCP connection attempts at port 53, temporarily blocks the port and writes the log message. After this point it can answer UDP DNS queries again and most queries succeed over UDP, which means the temporary blocking doesn’t affect much.
If WinBox was the one issuing the reboot command, it too will repeatedly tries to reconnect to the WinBox port 8291 and sometime you may also see the flood message at reboot for 8291, and WinBox takes longer to reconnect (PC already has access to internet but is unable to login to WinBox for a few tens of seconds). Another port I could observe was 2828, apparently used by UPnP, although UPnP is disabled on my router.
Yes I think that could be part of the reason, but what I observe is that on our main office network where there is lots of equipment running 24h/day I see this message immediately after the reboot (and I considered the same thing as you), however on other locations I see the message when the people come in during the morning. E.g. this was logged after a scheduled reboot last night at 01:01 to update to 7.18.1:
2025-03-04T01:01:17+01:00 MikroTik HeadOffice possible SYN flooding on tcp port 53
2025-03-04T06:06:52+01:00 MikroTik Branch3 possible SYN flooding on tcp port 53
2025-03-04T08:24:20+01:00 MikroTik Branch4 possible SYN flooding on tcp port 53
2025-03-04T08:52:10+01:00 MikroTik Branch2 possible SYN flooding on tcp port 53
The “packages” in RouterOS are said to be separate filesystems that are loop-mounted into the root filesystem at boot.
As each package filesystem is “compressed”, more compression can be gained by having everything together than by putting them all in separate filesystems (compression is based on coding repeatedly occurring patterns as a shorter sequence).
Also, a filesystem has overhead like a superblock, directories, etc. But I think that is quite small for squashfs, which I think they are using.
Assuming this is still about the “possible SYN flooding on tcp port 53”: YES. When having hundreds of clients on the local network, there can be enormous bursts of DNS requests. The CCR2004 should be able to handle that. I have configured 10000 concurrent requests and 1000 TCP connections and I do not appreciate that the service would then be temporarily cut off due to “SYN flooding”…
We have seen this behavior as well with winbox, but port 8291 was only exposed to management vlan and I’m the only one accessing the device during that time so this SYN flooding warning is just a fluke at least for me
I have an HEX (not refresh edition) that works fine on 7.17.2 but crashes on 7.18 and 7.18.1.
Recovery requires reset button to wipe config, after which 7.18.1 boots, I then downgrade to 7.17.2 and apply the backup and everything is fine.
As this is a ‘production’ router, in the sense I can’t have it down for too long, I’m unsure how to troubleshoot this. I do have the /export output so maybe I need to apply it step by step. I have submitted a Mikrotik Support Ticket with config from 7.17.2 that crashes 7.18.1 but haven’t heard for a week (I understand its a busy time)
I don’t mind that it logs a bogus message, but I worry that when it detects the condition (also later during operation, without logging the warning again) it will temporarily disallow new connections on that port.
In case of DNS that would cause users to experience delays e.g. when loading a webpage, and that is precisely what we observe.
I lately get those helpdesk tickets “the internet sometimes is soooo sloooow!!!” and it isn’t reproducible, but it could well be this.
Ok, with remove [find default=no] also my device is locked… probably the command is used before deleting existing queue simple/tree that use the type…
A manual reboot solved, not go on loop. NO. Must netinstall. after some seconds locks again.
/queue type
add kind=cake name=queue1
/queue simple
add name=queue1 target="" total-queue=queue1
/queue tree
add name=queue1 parent=global queue=queue1
Probably For sure removing the queue type before removing existing queue that use the type is the problem…
This is major fundamental issue with Mikrotik - any object can be removed even if it is used somewhere else. One example - on Fortinet devices every object has all references marked and can be removed only after all references to it are removed. This can avoid many similar configuration breakdowns…
This is just an example how it can be done right way. I have seen enough headaches with Fortinet just as with Mikrotik, but this is beside the point. The point is lacking this kind of basic sanity checks on configuration changes. Even if some bug will cause this and there’s no sanity check stopping it from happening and you are up to netinstall.
My first encounters with Fortinet made me furious because of this exact feature but one would quickly understand the value behind it, because with Mikrotik you end up searching manually for all these references which are shown to you in Fortinet GUI to help you and to avoid this kind of a situation from happening.
It is not as bad as you suggest. Yes, sometimes you can remove an object and leave something else dangling, but usually you will just get an “unknown” or some HEX number at the place where it was referred, and nothing bad happens.
This problem with queue deletion is apparently touching something more fundamental and causes a kernel crash.
That is bad, but it will likely be fixed ad-hoc and not by enforcing referential integrity at the basic level (which Fortinet apparently has).
There is always something to be said about the configuration mechanism.
Some people prefer a system where all config is only done in RAM and a “save” is required to commit it to nonvolatile memory.
Some systems have a “transaction” mechanism where you can change different parameters and “commit” the whole transaction in a single config change. Sometimes useful when you want to change things and the intermediate situation is not working or conflicting.
But every method has its advantages and disadvantages, and its overhead in software.
