For anyone considering the upgrade, MikroTik RouterOS 7.23.3 [stable] has been successfully installed and tested on the following hardware models:
The upgrade completed successfully across all eight devices, with no issues observed so far.
What I expect from MikroTik when they fix security issues is that:
It is clear that usually the fixes are in management interfaces and the impact is limited, but when it is in something like PPP or IPsec ISAKMP or other services that may be exposed to internet, we really need that information. Also when it is inconvenient or embarrassing to MikroTik.
Don't think that not disclosing such information hides you from exploits. It doesn't.
This is a fact.
Main problem here is that one event when changelog was modified removing the reference to security issue.
Once this kind of thing comes out, trust is breached.
That is exactly why Mikrotik looks more like Dropbox than other respected vendors of IT world.
RB5009UG+S+, CRS310-8G+2S+, and several CRS304-4XG were updated without any noticeable issues. However, a side effect became evident only after a long time: one VLAN on a CRS304 switch lost internet connectivity.
I was unable to identify during which specific RouterOS update this behavior changed, which makes this type of silent failure particularly difficult to diagnose.
The root cause was related to the MAC learning setting on a bridge port. Changing "learn=no" to "learn=yes" restored connectivity.
CRS317-1G-16S+
Cosmetic issue:
When I plug a Mikrotik base-T 10G SFP+ in slot 3, the link will be negotiated - but the leds of SFP+ port 11 will activate and signal activity and status (so port +8)
About 90% of our RB5009's will not update from within Winbox. We get errors such as ERROR: IPV4 or Calculating download size -- which it seems to get stuck on. However if I upload the .npk and reboot it upgrades. We have other devices such as CRS326, CRS310, CCR2116 that updated with no issues.
Hardly conclusive, but my RB5009's have always updated without issue. Myself, I'd check the environment first (and if you have a spare with the issue, test it with different external connectivity, and/or starting with a cleared config.) I would think that this part of ROS would be the same for all devices.
Oh, and you stated WinBox . . . 3 or 4? And have you tried via WebFig?
In another topic this was resolved to an MTU issue. It seems that the PPP set TCP MSS feature again stopped working, probably in the previous version then. When you have an internet link with less than 1500 byte MTU it stalls.
Try adding some mangle rules to the firewall to see if that fixes it:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
When there already were mangle rules, move these to the top.
These RB5009s have never had an issue updating in the past, they are located in different parts of the US and all of them have the same config. And it doesn't seem to matter what handoff we have to internet - fiber, cable modem, T-Mobile 5G -- same issue.
We run Winbox 4 exclusively. We don't generally run WebFig as they all remote and we don't allow access to WebFig.
Also devices behind these routers such as CAP AX (ARM64) update without an issue. WAP AX (ARM) fails. Since CAP AX upgrades work I would assume that since it goes through the RB5009 to get to the internet and Mikrotik's upgrade servers that the config on the RF5009 such as firewall, Mangle rules, etc are fine. And none of these devices have ever given us an issues while upgrading.
Have you tried first rebooting and then update? That can also help sometimes.
I'll be darned!! I rebooted the router and now it doesn't have a problem updating. Thanks for suggesting that as I had not even thought about rebooting it.
Yeah, I think that is a bug. But not really useful to report it, it is hardly reproducible.
cap-1: radar detected on 5500/ax/Ceee/D
Is this a false positive, I see no sign of a link down anywhere, not seen any sign of that behaviour for at least 18 months.
AI says...
In-Service Monitoring (ISM) GlitchWhen a 5 GHz radio operates on DFS channels, it performs "In-Service Monitoring." If a local client device with a noisy or poorly calibrated Wi-Fi chip transmits a sudden burst of energy right next to the AP, the MikroTik's wireless driver can mistake that burst for a military or weather radar pulse. is this true
The Dude Response
Yes, in principle that can happen on DFS channels.
However, this is not the normal behavior for ordinary client traffic. A properly operating client should not normally trigger DFS radar detection.
Old wireless driver detected dfs several times a day, since I switched to wifi-qcom-ac it stopped. I could even trigger a DFS event by toggling wifi on my Huawei tablet (rip, its battery went up in flames last year).....
Have the same issue.... Slow downloads / updates from routers and also mikrotik download
Is it still possible to copy an entire partition to/from a 7.23.3 partition? I hope they do not break that, it is a standard procedure here to copy to 2nd partition regularly and at least before upgrade.
That should work as partition cloning does not care what is on target partition as it is erased at the start.
It is most probably a bug which makes 7.23.3 partition unrecognizable to other versions.
