so I updated from 7.21rc2 to 7.25rc4 and now can not acess webfig via browser or conect via ssh / winbox using IP adress ?
can still get in via winbox MAC adress
added the Avaiable From ranges also , and did a full Shutdown / power off and back on
why were you running such an old rc? how did you get access to unreleased 7.25rc4?
not too sure why your calling it a old release I only last updated them 48 days ago ... also had to upgrade winbox from 4.1 to 4.4 or else it would not even connect via MAC without crashing ...
also it's what mikrotik upgrades to when you tell it to look for updates ... so no idea what your on about ?
even dropping to 7.24.5 still can not get acess unless via MAC ?
7.21rc4 you call recent? you're mixing up versions. first you said 7.21rc2. your screenshot says 7.21rc4 installed. and upgrade version is 7.25rc1.
Your devices have 48 days of uptime ... which today sets latest reboot to around mid of August of 2026.
But if you look at timestamp shown with version (and those are usually quite aligned with release dates), you can see that those 7.21rcs go back into end of year 2025. I'm not saying that you didn't install those year 2025 RCs in mid of August of 2026, but if you did you had to make some effort (and presumably have some reasons to do so). And that doesn't make them any less "ancient".
Also, RC versions are considered "work in progress" and normally one should not run them after actual version gets released. Unless one knows much better.
yes 48 days ago was last time I did a mass update on routers I had physical acess to
and the last version that they were able to fetch was 7.21rc
today I did check update and went to to 7.25rc4 and then lost ability to get into them
via IP / ssh / webmin it appears the firewall configs got messed with during the update as even after downgrading down to 7.24.5 it would not work , and I had to rebuild configs
7.21cr4 was on another router I hardly touch that would have been done beginning of year
I had to use the rc because of incompatibilities with the removal of the wifi driver I used to use,
at the time that was the only options that had both versions available
for that wifi the newer mikrotik router's I got only used, which turned out to be just a POS !!!
wifi qcom absolute garbage
however now the wifi links between them are extremely unstable after putting 7.25rc4
onto the RB2011UiAS-2HnD even after rolling back to 7.24.5
old legacy wireless
I might just have to drop back to the
7.20~7.21 ranges ...
Something has been very wrong 48 days ago....
If 48 days ago the latest version you could fetch was from END 2025, something was REALLY wrong.
Besides, mass update and use rc version ?
I don't get it...
Mass upgrade to an rc version? Not sure what planet you are on, but I would never mass upgrade to an RC not to any production unit. RC is for testing.
The top screenshot from the post I'm replying to is also very very suspicious. Your device has channel set to long term and yet it's offering you a rc ... I've never seen rc being offered outside testing channel.
Compromised device?
User happily cycling channels and hitting "check for updates" button. 
Hello.
Has this version fixed the issue where skins saved in the "Skins and User Groups" section were not displaying? This is the problem I had previously reported to your support team.
Does this case mean the same thing? => winbox - fix the Skins menu for user groups opening a non-existent window;
Just check if this version solves the and inform us what the result is. Please.
There have been several MLAG problems reported lately and now 7.25 adds things like "mlag-lacp-fallback" and "mlag-init-delay".
That’s great, but we don’t even know what problems these are supposed to address or how they work, and the total lack of documentation on what they actually do, their defaults, and their expected behavior makes proper testing pretty much impossible.
If MikroTik wants useful testing and feedback from the community, changes like these really need to be documented when they’re introduced.
The links below are only examples of reported MLAG issues from 2026, and there were plenty more MLAG-related reports during 2025. I’m listing them mainly to show the scale of the problem and how many issues still seem to remain around such an important feature.
MLAG is not just something for a home lab where the occasional odd failover can be tolerated. It is used for high-availability, high-scale designs, including datacenter environments, where redundancy and predictable failover simply have to work. For that kind of feature, both the implementation and the documentation need to be held to a much higher standard.
It is of course very positive to see MikroTik actively working on these MLAG issues, and that effort is appreciated. It would just be very helpful if the communication around changes like these could be a bit clearer, especially when community testing is expected to help verify them.
Thanks for continuing to work on this.
--
2026-10-01 - MLAG failover: 2 minutes?
https://forum.mikrotik.com/t/mlag-failover-2-minutes/273498
2026-09-26 - MLAG between CRS326-24S+2Q+ and CRS320-8P-8B-4S+
https://forum.mikrotik.com/t/mlag-between-crs326-24s-2q-and-crs320-8p-8b-4s/273392
2026-09-18 - Multiple MLAG pairs
https://forum.mikrotik.com/t/multiple-mlag-pairs/273236
2026-09-12 - 7.25beta - MLAG heartbeat loss/anomalies
https://forum.mikrotik.com/t/7-25beta-development-is-released/272788/271
2026-07-01 - 7.24beta - MLAG forwarding/FDB convergence problems
https://forum.mikrotik.com/t/v7-24beta-development-is-released/270782/196
2026-06-05 - MLAG status in 7.22/7.23?
https://forum.mikrotik.com/t/mlag-status-in-7-22-7-23/270934
2026-05-18 - MLAG hopelessly broken? - STP state synchronization
https://forum.mikrotik.com/t/mlag-hopelessly-broken/167137/85
2026-04-27 - Bridging hosts not forwarding
https://forum.mikrotik.com/t/bridging-hosts-not-forwarding/270143
2026-04-15 - MLAG configuration for v7.22.1
https://forum.mikrotik.com/t/mlag-configuration-for-v7-22-1/269918
2026-04-06 - MLAG + VRRP failback issue
https://forum.mikrotik.com/t/mlag-vrrp-failback-issue-vrrp-master-does-not-process-vip-traffic-after-recovery-rb4011-ros-7-22-1/269687
2026-03-29 - MLAG FDB host table duplication
https://forum.mikrotik.com/t/mlag-fdb-host-table-duplication/269518
2026-03-19 - MLAG between CRS326-24S+2Q+RM with more than 1,000 hosts
https://forum.mikrotik.com/t/mlag-between-crs326-24s-2q-rm-with-more-than-1-000-hosts-macs/269294
2026-03-09 - MLAG + VLAN filtering = RSTP breaks everything
https://forum.mikrotik.com/t/mlag-vlan-filtering-rstp-breaks-everything/269081
2026-02-28 - VRRP + MLAG Issues
https://forum.mikrotik.com/t/vrrp-mlag-issues/268869
2026-02-13 - MLAG and STP
https://forum.mikrotik.com/t/mlag-and-stp/268553
2026-01-13 - v7.21 - MLAG/LACP MAC/ARP connectivity regression
https://forum.mikrotik.com/t/v7-21-stable-is-released/267773/53
Exactly; it's being marketed as such at the very least.
I love it... when it works. It's infuriating when it doesn't, and when it doesn't, it's usually associated with another outage, so it's hard to pin down the problem to the MLAG, the other equipment failure, or both.
I'm not sure it's new in the 7.25rc1 netinstall.npk since it seem to happen when downgrading to 7.24, but when I tried to netinstall some older wAP, it gets stuck at "booting" and never starts the netinstall. And package uses "smips or mmips" as the architecture , maybe's that's right at the point of the netinstall EFI boot...but they do actually have different packages to install. Other newer devices were fine. I have not tried using a netinstall-cli to see if that fixes it yet, but it was 4 wAPs that also failed similarly, but do boot okay, so it's not one bad device.
Loaded this to a test box with a reboot notification script that compares old and new firmware version, and noting if an update was recommended. This worked on 7.22.x, 7.23.x (went to 7.23.7 as part of this test, as well as 7.24.5. Fails on 7.25rc1 . . .
Specifically, the line:
if ( $currentFirmware < $upgradeFirmware) do . . .
Now fails with
(mac-msg(winbox):admin@F0:DE:F1:71:77:E8) Script Error: cannot compare if string is less than string (:if; line 21)
Despite having printed the values of those two variables correctly in the two proceeding lines.
Comment out just the if, and it again runs fine . . .
(The values are pulled by the script via:
:local currentFirmware [/system routerboard get current-firmware]
:local upgradeFirmware [/system routerboard get upgrade-firmware]
)
Basically a blank test router (hEX update E50UG) with a clean config . . .
Otherwise, this string of updates went in 100% clean.
PS: The only thing I can think is that the "if" is intolerant to non-numeric chars . . . never loaded a test/dev build with this in place, so might be that simple . . . )
If the firmware only contains numbers and decimal places then its actually being treated as an IP address (can verify with ':put [:typeof $currentFirmware]' but can still be compared as its numerical. But as soon as it contains a letter i.e. "RC" then its a string and can't be compared. It's like asking "if crayon is less than building" it makes no sense
You'd have to do some string manipulation to strip and convert it, but honestly i'd just let it fail. You should never script or automate an upgrade to an RC version. I'd argue you should never automatically upgrade anything and it should be a careful and delayed process to vet it thoroughly unless you absolutely need a certain fix/feature
It's not in any way an automation. It's a reboot notification script that has the feature of noting a mismatch in it's message, reboot reason, versions, last few critical events (if any), etc. The info is there already - dropping the line simply drops the implicit notifiction. It runs from the system scheduler at startup.
I have a unit in a very remote location with craptastic connectivity, and need to run a ping watchdog (it's a WiFi to WiFi config to insert an ipsec tunnel from behind a remote wireless network, and their AP's sometimes get stupid and won't pass traffic. The watchdog gets it back on one that is working . . . ) . . . This tells me of that, power fails, crashes, tenant screwing with it events, etc.)
I had researched and noted the (mis)feature of "automagic" type assignments so will try a "!=" comparator before I just either leave it commented out (or accept it in the rare cases I rest rc or other pre-release builds . . . )
And thanks!
Update: Going to "!=" has it working again, and makes more sense. I want to know of a mismatch, no matter what, not just lower. Still remains to be seen what happens if one is alpha, and the other numeric, but much closer now.)
And before anyone calls me out on talking wireless and this being on a hEX refresh, the use case is primarily on AP's (but I run it on all ROS devices, along with emailing crit log entries). I simply tested pre-release stuff on a non-prod device that was laying around and saw this.
So, please ignore this as not actually a 7.25rc issue!
Final update: The "!=" test instead of "<" appears to be working even when one value is numeric and the other has alpha+numeric chars, fwiw . . .