a feasible (interim) solution would be switch to stable branch 7.24.2 for dhcpv6 / ipv6 until another release on long term branch if those features are required
Why would I upgrade to a later version when it makes some of my older wifi devices unstable ?
I've tried them all and since installing anything with the new wifi driver from version 7.24 through to the latest 7.25beta causes a lot of disconnects on various devices vs 7.23.4.
7.23 stability as follows. If you have all the very latest minimum ax chips in your devices then yes you might have a point, but with older devices stay on 7.23.4 or unless you 100% need ipv6 of course.
Hap ax2 on 7.23.4 stability speaks for itself right here............
0 A interface=wifi1 uptime=16h26m28s signal=-57 band=5ghz-ax auth-type=ft-wpa3-psk tx-rate=960.8Mbps rx-rate=1020.8Mbps
1 A interface=wifi4 uptime=16h26m26s signal=-71 band=2ghz-n auth-type=wpa2-psk tx-rate=72.2Mbps rx-rate=39.0Mbps
2 A interface=wifi1 uptime=16h26m21s signal=-59 band=5ghz-ax auth-type=ft-wpa3-psk tx-rate=6.0Mbps rx-rate=6.0Mbps
3 A interface=wifi2 uptime=16h23m22s signal=-57 band=2ghz-n auth-type=wpa2-psk tx-rate=144.0Mbps rx-rate=130.0Mbps
4 A interface=wifi2 uptime=15h33m4s signal=-60 band=2ghz-ax auth-type=wpa3-psk tx-rate=1000.0kbps rx-rate=11.0Mbps
Long-term releases are usually ones where one would trust that nothing would be broken between releases.
This trust is now broken as one feature (not even mentioned in changelog) is broken and this leads mind to question "what if there's more?" - and there is. Trust in reliability of these releases is even bigger feature to be broken than DHCPv6 client.
Can't be more agree on stability for long-term branch but in the context of sudden / urgent release this time, I think the criticality outweigh the testing time for the long-term release. Anyone who needs dhcpv6 / ipv6 can try with stable branch release which proved with this feature working, until the next release of long-term branch lands.
I really hope that there's nobody in MT management that would make a policy (just "for a display" how "Mikrotik keeps security an integral part of its' operations" without actual meaning) for regular "urgent security updates" to be released even if there are no actual need to do these the way we already had two in 2 months.
Having vague explanations and https://mikrotik.com/supportsec being unattended for 12 months might drive more towards this kind of "conspiracy theories" than anything else
"Critical security update", "most of configurations not affected" and device "could be at risk". Vague self-contradiction is not a way to maintain credibility.
It's hard to say how you have configured your devices, and also hard to say how an attacker would approach your network. So better upgrade, than be sorry. We are staying on side of caution. We are not sharing specific details to allow people to upgrade before a widespread attack happens.
How do you deal with RouterOS instances which are running out there, mostly unmaintained with some old 7.x? What happens to them once zhe details are published? Are these devices doomed?