As @Amm0 said, but with changed emphasis, the root cause was the new driver that was not tested enough with older hardware (older generation, but still available to buy and working perfectly), in other words: it was rushed and then didn’t receive any further love.
I would (kind of) understand problems with hap ac2, with 128 MB RAM, but I cannot understand them happening to hap ac3 with 256 MB. This is definitely not only the RAM problem. Also not the storage (“disk space”), because nothing is being written there. I could cause the issue sometimes by initiating a download with many parallel connections, but not always, so there had to be more. By eliminating one by one service, I finally stumbled across “neighbors” (although I use them often and consider them useful, it didn’t appear as a big CPU hog and it it turned on by default) so I turned that off and voilà, no more reboots, even with multiple simultaneous downloads.
I don’t remember this “sold as WiFi 4” part, I thought that AC was WiFi 5, but with qcom-ac it is definitely working as it should have been from day one.
And I definitely agree that this “kernel panic” situation should be dealt with by Mikrotik. I have updated my ticket I had open since May 26, so I hope that someone will take a look at that…
Nice find @infabo , that confirms my thoughts that RAM is not the problem.
There are 25 neighbors total in my case: 7 CRS switches, 9 CAPs, 4 Wireless Wires and 5 Linux servers. Now, could it be that the Linuxes are somehow killing the CAPs? But then, why only in this location?
In have “lldpd” running on all of my Linux boxes, with options “-M -cc”, -M1 meaning “Generic Endpoint (Class I)”, and -cc meaning “force CDPv1”, and it has been turned on for years.
BTW, I have now upgraded all of the CAPs to 7.20.6 (from 7.13.5 and 7.17.2 which seemed to be most stable versions) and will monitor them closely…
Recently (~2 weeks ago) I disabled everything in device mode except bandwidth test. That might be why there is now more free ram. Just a theory - I have no historical data. Maybe someone with monitoring history can give it a try?
/system/device-mode/print
mode: advanced
allowed-versions: 7.13+,6.49.8+
flagged: no
flagging-enabled: yes
scheduler: no
socks: no
fetch: no
pptp: no
l2tp: no
bandwidth-test: yes
traffic-gen: no
sniffer: no
ipsec: no
romon: no
proxy: no
hotspot: no
smb: no
email: no
zerotier: no
container: no
install-any-version: no
partitions: no
routerboard: no
attempt-count: 0
The idea of disabling unused features via device mode was driven by these changelog entries, as well as my impression that some unused processes may consume valuable ram.
What's new in 7.21rc2 (2025-Dec-15 11:35):
*) hotspot - prevent service from starting unnecessarily in the background on export/print commands;
What's new in 7.21beta2 (2025-Oct-06 16:06):
*) detnet - fixed unnecessary process starting even when feature is not enabled;
I have to disappoint you, but the moment I turn on SNMP - kernel failures start to happen
It’s not just “turn off neighbor discovery” but “turn off EVERYTHING” if you want your CAP to survive more that a few hours. I tried turning on SNMP yesterday and regretted that almost immediately - had two reboots in 3 hours, turned it off again (btw, I am monitoring CPU usage and network traffic stats every 5 minutes - I wouldn’t say that is too often for a 4-core router).
On a “bright side”: all CAPs I upgraded to 7.20.6 3 days ago are still alive (with everything possible turned off, of course).
Hello, friends. I am responding on my part... The last step i made was to turn off "/ip neighbor discovery-settings set discover-interface-list=none". This happened 5 days ago. Yesterday, one AP had a "kernel failure"... Nothing new here
Yes, yesterday afternoon and this morning 3 of my hap ac3 CAPs had kernel failures with everything possible turned off. RouterOS is 7.20.6. They managed less than 4 days. Other 3 are still resisting.
as described earlier, 7.13.5 here (considered probably still as THE MOST stable ROS on .ac devices), clean NetInstall on ALL devices, and Kernel failures Now i turned off also some “Services”. I think not too much options left… (AP U7 Pro etc…)
Hi, not sure if you still facing this issue, but when i opened a ticket to Mikrotik Support the response I received for 2x hAP AC2s is: “We can not be 100% sure yet, but it seems that the problem appears only if your 2 GHz wireless is running on a busy frequency. We are investigating the issue, but seems that this might be the key here.”
What I did that fixed it for me was changing the 2.4Ghz config for both ac2s to “channel.band=2ghz-n .frequency=2412 .width=20mhz”. Since then it is/was stable with all 7.20.x versions. Currently running v7.20.6 and planning to upgrade to v7.20.7-longterm.
Same here. Since the release of the wifi-qcaom-ac driver, I have been using it on a total of three hAP ac² CAPs controlled by CAPSMAN and have never had a crash.
@sinisa
I noticed a few possible errors in your configuration.
You are using VLANs for the CAPs and also have VLAN filtering enabled for the bridge. However, there is no VLAN interface for L3 communication; instead, the IP address is assigned to the bridge via DHCP client. The discovery interface for the CAPSMAN should also be the VLAN and not the bridge. I can't say whether specifying a datapath can cause problems, but in MikroTik's example for the wifi-qcom-ac driver, the setting has been omitted.
/interface wifi
set [ find default-name=wifi1 ] configuration.manager=capsman datapath=capdp disabled=no
set [ find default-name=wifi2 ] configuration.manager=capsman datapath=capdp disabled=no
For the CAPSMAN, the configuration for the 2.4GHz channel is not specified, but I suspect this is just an oversight when copying and pasting. The rest looks fine so far, but I'm a little surprised by the frequent reselect interval.
It's especially odd if it's the hAPac3 as reported in thread... since that has more memory than the wAPac/hAPac2.
Anyway, If you're getting "kernel failures", especially on a 16MB flash devices (like hAPac2), netinstall be highly recommend to get the wifi-qcom-ac package installed. The only times I've had problems with the wAC and hAPac2 is if unit was not netinstall'ed for V7 - but I have seen panics as result of lack of disk space, especially since we tried for a while to use zerotier package with wifi-qcom-ac, but that become impossible in later V7 release. But I will say we never had issue with hAPac2 and wAPac that were reformatted by netinstall, they all seem to work fine (*with only the wifi-qcom-ac and NO other packages).
Now i turned off also some “Services”. I think not too much options left… (AP U7 Pro etc…)