we would like to share a short recovery case involving an hAP be³ Media (MA53UG+HbeH).
After experiencing an unstable condition that could not be reliably solved through incremental configuration changes, we decided to return the unit to a completely clean state and rebuild from a known-good baseline.
The recovery procedure was:
factory-clean configuration;
RouterOS updated to 7.25beta5;
RouterBOOT upgraded accordingly;
wifi-qcom-be and container packages aligned to the same release;
initial validation performed with the router isolated from the production LAN.
The clean baseline successfully passed:
two consecutive cold boots on the bench;
a further cold boot with the Fastweb WAN connected to ether1;
successful DHCP lease acquisition on the WAN;
normal Internet connectivity;
working Wi-Fi;
approximately 900/900 Mbit/s throughput.
At this point we created both an .rsc export and an encrypted binary backup as our GOLDEN baseline.
We are now restoring the previous production configuration progressively, rather than importing it all at once, so that any configuration element capable of reproducing the original issue can be isolated.
Therefore, at this stage we are not attributing the problem to RouterOS 7.25beta5 or to any specific configuration component. What we can confirm is that the device is currently stable from a completely clean 7.25beta5 baseline.
Apart from the recovery exercise itself, the hAP be³ Media is proving to be a very interesting device to work with. The combination of RouterOS flexibility, Wi-Fi performance and the amount of configuration freedom makes this kind of controlled testing surprisingly enjoyable.
We will update the thread if the controlled restore identifies a reproducible trigger.
It is already a known fact that applying ROS 7.25beta3 (or later) fixes most issues on hap be3 media for those devices which came out of factory with a nightly build 7.25_ab170 (or alike) of routerboot but ROS version 7.24 (something) as OS.
Thanks, this is very useful and it actually matches our unit quite closely.
Our hAP be³ Media came with:
RouterBOOT factory/current: 7.25_ab170
RouterOS: 7.23.2 (factory software 7.23.1)
wifi-qcom-be: 7.23.2
container: 7.23.2
So in our case the version mismatch was even slightly wider than the 7.24.x case you mention.
We moved directly to 7.25beta5 and aligned RouterOS, RouterBOOT and the packages before establishing the clean baseline described above.
Our intention with this thread is mainly to document the recovery path and the subsequent controlled restore, rather than to claim a new issue.
Thanks for the references — they are very helpful. Aster & Enrico
Tutto questo malloppo solo per dir ciò che già si sapeva:
funziona solo con la 7.25 beta,
perché hanno avuto fretta di immetterla sul mercato con la 7.25_ab170 a cui è stato fatto il downgrade alla 7.23.2
per non far dire alla gente "ehi, ma mi gira con la beta..."
EN: All this fuss just to say what was already known:
it only works with the 7.25 beta,
because they rushed to get it onto the market with version 7.25_ab170 which was actually downgraded to 7.23.2
just to prevent people from saying, "Hey, but it runs on the beta..."
Thanks. I agree that the RouterBOOT/RouterOS mismatch is now well documented, and that 7.25beta3+ appears to address several hAP be³ Media issues.
There is one point I would keep separate, though: 7.25_ab170 is a RouterBOOT version, not a RouterOS version. So an hAP be³ Media shipped with RouterBOOT 7.25_ab170 and RouterOS 7.23.2 clearly shows a version mismatch, but by itself it does not prove that RouterOS was first installed as 7.25 and then deliberately downgraded to 7.23.2.
Likewise, I have not seen an official MikroTik statement explaining why those units were shipped in that state, so I would rather not speculate about the reason.
For our unit, the useful fact is simply that aligning RouterOS, RouterBOOT and packages on 7.25beta5 produced a stable baseline. Aster & Enrico
.