i was able to restore peers working by importing the self signed ca cert…
this really is not nice of mikrotik to release that kind of unstable software to a stable branch!
Looks like trust state for some certificates is not stored properly, though displayed correctly. I think this helps once and for all:
/certificate/set trusted=yes [ find where trusted=yes ];
i have one peer left that not work
can’t verify peer’s certificate from store
i have reimportet the certificate and ca crt but it is not working …
UPDATE!
I have rebootet the device and now the last peer conected → thats no enterprise level product!
Thank you
Which is why I mentioned it to you earlier this might apply…
for hapac2 i give up on using wifi-qcom-ac though its performance is much better with legacy wifi driver (wireless package) because of this never ending storage issue that can mikrotik fix if they just only care, we can’t justify to throw 300+ hapac2 working in the field
For my hAP ac2 I still use the traditional driver for a couple of reasons. The free storage decreased by about 120kB to 832kB now, which is still plenty.
I think the general standpoint of MikroTik is that every device has the functionality it had when it was released, and any new software that came later is only a gift and not part of your deal. It can increase functionality, it can cause problems, you install it at your own risk and at your own decision.
Hmm, no… That does does not (always) work. So for now removing and re-importing is the only reliable way.
well, you are right I accept that fact already but it doesn’t make any sense at all to release wifi-qcom-ac driver for hapac2 knowing that it will cripple the device what’s the point? to force the user to ditch hapac2 in favor with more recent device? anyway that’s life isn’t it? hehehe
Yeah but the wifi-qcom-ac driver is not “for hAP ac2”. It just happens to have the right chip to work, but not enough storage.
Similarly the same driver “works on RB4011” but then it only supports the 5GHz WiFi and 2GHz WiFi becomes completely inoperative.
You cannot install the “wireless” driver for 2GHz support either (or have a pre-7.13 RouterOS where “wireless” was part of the main package), it simply will not work when wifi-qcom-ac is installed as well.
When you are talking about crippling the device… I cannot understand why people would want this.
And it causes trouble for others as well, as this RB4011 “support” takes up space in the wifi-qcom-ac driver that others need so desparately.
I updated the router to version 7.19.
The router was acting as a WireGuard client. The server part remained on the old version.
After the update, I can no longer restore the connection. The log shows: “wg_5: [peer_5] xxxxxxx=: Handshake for peer did not complete after 5 seconds, retrying (try 2)”.
I tried reconfiguring everything, but nothing helps – it seems like it’s connected, but the connection doesn’t actually establish.
The issues with certificates in this thread probably have something to do with this change item:
*) certificate - optimize trust store;
I noticed after upgrading another one of my routers today, that had the 140 CA cert bundle installed, that just upgrading while keeping all those CA certificates reduces the storage used by them (about 1MB in previous RouterOS version) by over 500KB. Which means the upgrade did perform some conversion of the stored certificate to reduce their size (removing those CA certs to only use the built-in one further frees up 500KB).
Maybe the conversion messed up with the trusted flag.
All certificates imported with RouterOS 7.4 or before suffer this issue. RouterOS 7.5 had a change to import the certificate with trust that RouterOS 7.19 understands.
The wifi-qcom-ac cripples any device for which it was supposedly developed…
Whether it is just a lack storage space issue, but also lack of RAM issue and frequent OOM reboots if your AP load is higher and has only 128.0 MiB RAM like on hAP ac or cAP ac and in some cases not being able to support 2GHz issue like on RB4011.
And I haven’t seen any promised performance bust on my heavily loaded devices which is why I just gave up and stopped trying, legacy wireless driver is working just fine without any problems and reliability issues so for me development of wifi-qcom-ac is just a waste of time and it seems that MT also realizes that and is phasing out the support for it and would of course much more prefer for users to just buy newer products that where design around newer drivers.
But for people playing with wifi-qcom-ac I don’t see the reason to complain since it is their own choice to use something their devices were not designed for in the first place expecting to gain newer devices permeance for free 
I’m now trying out Quad9 DoH again using the Internal certs, I’ll keep you all posted!
1 Like
well I don’t see something wrong to maximized what you paid for the device wifi-qcom-ac gives boost to hapac2 in my use case it’s just the storage issues kill and i give up
wifi-qcom-ac contains over 700KB (compressed size) driver files only used by two device families (one is the RB4011) that are useless on all the other hAP and cAP devices.
We have found out that universal package from our help page which enabled protected bootloader do make RB5009 devices unusable. This has nothing to do with v7.19. The problem has been there for a while already.
It is not possible to fix an already damaged router manually - the router must be returned to the seller for warranty repairs.
ok, i have one 5009 left which is working for now … until power is applied
but, IDK is it going to boot ?
so ? from where to download fixed BB until device is still alive ?
The qca9984 drivers and firmware are closer to 1MB in size (compressed) and adding those does make wifi-qcom-ac significantly larger than the legacy wireless, although it is not an issue on either RB4011 or Audience which are the only devices using qca chipsets as far as I know.
So yeah maybe MT could create new specific package called wifi-ipq-ac without those qca files for devices that only have IPQ-4xxx chipset and that would be much smaller but that would require some additional developer time which I am not sure MT would willingly assign and would not solve OOM issues on smaller devices…