MikroTik do not pull firmware when bugs are discovered, so it remains your responsibility to check the forum to see if others have run into insurmountable problems (with a similar device or use-case as yours) before deciding to apply an update.
Of course, waiting for a week will give others more opportunity to post their findings.
What if everyone waits ?
every new release brings so many changes that you can wait only for so long to test the new bugs features that you've been waiting for a decade!
Then nobody is affected by the new bugs! 
On a more serious note: the recommendation is to wait one or two weeks before installing it on critical equipment. Of course, not so critical hardware - or even a test on, inside your own lab! - are a different question, and these are why we recommend waiting one or two weeks. Probably someone will run into problems when doing validation, before deploy on large networks.
Like VTI for example!
Thankyou V much Edgars -
Indeed we were earlier adopters of QoS features and at the time followed the deployment guide.
My big mistake here was that when we labbed this, we removed those lines as now we are using vpls for our customer traffic.
little did I know how dangerous that little line was to becomeā¦
And when we deployed to the other arm of the network, the day before, that arm did not carry the particular customer traffic we were seeking to QoS, so therefore upgrade went smoothly on that arm. The one thing that does still mystify me is that the CRS318 on the redundant path that we had updated the night before DID have that config - but was unaffected. oh well.
Hopefully prevents someone else having the same issue, although it is quite obscure.
For those of you above backing me, thankyou.
There are many with big system that do need to test the new releases, and they test it on non production. So wait som weeks is a good habit when installing new software/os etc.
Here is a quote of my self:
Here is what you should do:
Do not upgrade .0 version. Wait to at least .1
Do wait some weeks after a new release to upgrade to make sure no surprise are lurking in the shadows.
Read forum and see what other says.
Then upgrade a local router with same config as the remote and test it (if possible) (if you have remote routers)
If all looks fine, do the upgrade, but only if its needed. Why fix some that is not broken.
The downside of staying at an old 7.X version is that, if you need to upgrade to 7.(X+n) for some reason (you need a new functionality, something gets fixed, ā¦) then you can have more potential problems at the same time, especially as n gets larger.
But, of course, what you say is reasonable.
Because the "old" ACME certificate (generated pre-7.22) was not successfully migrated to the new ACME implementation.
If you are already using the "new" ACME certificate, delete the old one from the certificate store.
Yeah I usually wait until at least .1 but did not this time as I needed the new features for a major system upgrade - however though regardless that wouldnāt have helped me this time because the bug has been in existence for several major releases.
Have you tried in an incognito window?
after upgrading from 7.20.8 (hap ax3) , my slave wifi interfaces never got IP anymore. I wasnāt been able to solve this so had to revert to 7.20.8 devices connecting to the wifi ssid on the slave interface but never get to the DHCP server. I was trying to add a new datapath, (vlan100 tagged => master interface = works , vlan400, slave interface => not working. dhcp is on the vlan interfaces, everything was working before the upgrade. Thankfully working also after downgrade. no issues in vlan tagged ether interfaces though so its some wifi āfeatureā .
the only thing I see in the log is that device is associated, and disassociated to the slave interface. Since slave interface cannot be added to a bridge anymore, not sure how to solve this.
reading that others have similar issues too, no idea really
any help appreciated.
Within reason, multi-driver wifi packages can be ālargeā on devices that have decent or better flash storage capacities. The painful, ongoing problem is on devices that have limited flash capacity. Thatās specifically the Chateau D53 models, hAP ac2, cAP ac, cAP XL ac, LDF 5 ac, LHG XL 5 ac, LHG XL 52 ac, NetMetal ac2, mANTBox 52 15s, wAP ac (RBwAPG-5HacD2HnD), and SXTsq 5 ac. Every one of these devices has either Qualcomm IPQ4018 or IPQ4019 chipsets, and they all have tiny 16MB of onboard flash storage with a little variation in how much flash is usable.
I think thereās a really simple fix available here: introduce a āwifi-qcom-401xā driver package that ONLY includes IPQ4018/4019 driver support. (Or wifi-qcom-4x if an even shorter name is desirable.) If for some reason MikroTik doesnāt want to increase the number of wireless driver packages they maintain, no problem: just shift the non-IPQ4018/4019 device support from wifi-qcom-ac into wifi-qcom.
There are literaly 2 devices that use QCA9984, which makes wifi-qcom-ac package too big, ahd those are RB4011iGS+5HacQ2HnD-IN and Audience and both are pretty old and work well with wireless package, RB4011iGS even better since it is the only way it could support 2.4 Ghz wifi, so the simplest solution would be to just remove QCA9984 from wifi-qcom-ac and let those 2 old devices, which will likely be discontinued soon enough, use wireless package...
The wifi-qcom-4011 package is what I was suggesting referring to RB4011, although it should probably be called wifi-QCA9984, and it seems the only viable option if MT is to support ac on these 2 devices because wifi-qcom does not support IPQ-4019 which Audience uses besides the QCA9984...
No, Audience doesn''t "work well with wireless package". Even more, using wifi-qcom-ac doesn't disable any of radios (unlike on RB4011 where 2.4GHz radio is only supported by wireless package). OTOH storage on Audience isn't tight and could work with wifi-qcom (if necessary drivers were part of it). Also mind that Audience is built around IPQ4019 and requires IPQ4019 wifi driver to operate two of its radios (2.4GHz and lower-5GHz ones).
And I full heartedly disagree about obsolence of Audience ... currently there isn't a more modern device with similar characteristics. We're still waiting for Audience ax (or be).
RB4011 wifi OTOH was always a marginal device due to weird combination of form factor and wireless.
So actually we need two packages:
I am sorry that I heart your fillings but it works well enough for me, I would say that wireless is actually more stable even if somewhat less performant...
I know that wifi-qcom-ac disables 2.4 Ghz only on RB4011 and I know that both use IPS4019 otherwise I wouldn't have said it so in my post.
On the other hand I see that your heart weirdly enough belongs to Audience device but it too doesnt seem overly popular otherwise it wouldnt be the last device left to receive long overdue ax upgrade let alone be, but as I said if MT insist on supporting these 2 niche devices they can always make separate package for just them and make millions other users happy...
Although I am pretty sure nothing will change and major number of MT users that are still using those 16MB devices we will be left living risky life with every update potentially bricking their devices...
I already predicted the confusion of the package naming of the qcom split. So many topics since then where people are confused on which package they need.
now 7.23beta and no move. The only thing I recognize, free flash space gets less and less on each ROS release I install on my cap ac. Already at 164kib remaining, on a dumb cap running nothing else than dumb AP.
Well then. So use wireless package on your hAP ac2 or cAP ac or whichever of those ac 16MB devices you're using with wifi-qcom-ac and your eyes are sore due to lack of flash space. I can asure you that it works well on hAP ac2 (or it used to in v6 times, I never ran wifi-qcom-ac on mine for exactly the flash space problem and I don't even run any wifi/wireless at the moment, it runs as wired router/CAPsMAN only). But don't mess with Audience, it was mediocre AP before wifiwave2. Even though it's "only WiFi5", with wifi-qcom-ac it works as good as wAP ax with most modern stations I have (e.g. Samsung A56 or S25 ... and I'm talking about actual performance, not theoretical peak values).
Hey there!
Is anyone having issues with RA and DNS servers for IPv6 with this new version 7.22? I have a weird situation: setup with a 4011 as main router + hAP-ax3 as an access point, with VLAN filtering (full trunk, no default vlan1). The vlan that acts as management vlan (main one, the one tagged in bridge for ax3, with access to cpu) doesnāt receive DNS from RA, so wifi devices connected to ax3 for that particular vlan has IPv6 addresses, but not DNS addresses. All the rest of vlans work just fine. This is happening in both, 7.22 and new development version 7.23beta2. As soon as downgrade to 7.21.3, problem stops.
Debugging it a little bit, turning on radvd logging, I can see the router solicitation / router advertisement are there in logs, when a wireless device join to this vlan. However, the DNS is not installed in the final device for this particular one. Same device, connect to a different SSID mapped to another vlan (other than this one) receives the DNS server just fine. All interfaces has the default ND configuration, announcing the same DNS form IP > DNS.
Anyone faced similar issues with RAs?
