So the device itself (cap ax) does not crash - "only" the 5ghz interfaces do not come up again after a DFS event?

It seems to be related to DFS (hence only 5 GHz) and the specific position that they are located in, but definitely not hardware and/or config.

If DFS is playing games, then it's mostly configuration (if device admin sees radar detections, then he should set other channels to operate on) and only partially software (yes, radar derection could be more robust, but robustness somehow goes against regulatory requirements about immediate stop of any transmission if radar is detected ... and robust detection takes time). One might argue that radar mis-detection is partially also due to hardware (WiFi receivers could be better).

I would say that when the operator has not set specific channels, a DFS event occurs, and the AP cannot decide on another channel, it is a device problem not a configuration problem.
However, patience may be required. Some countries mandate that the AP monitors a new channel for 10 minutes before it starts transmitting. When within those 10 minutes a RADAR signal is observed, it must select another channel and the 10 minutes start ticking again. When the AP has been down on 5GHz for 15 minutes or so, the user may have concluded that it has crashed, while actually he "just needs to be more patient".
It would be nice when the AP would make (more) effort to monitor several channels at the same time while looking for a candidate channel...

It would be nice when the AP would make (more) effort to monitor several channels at the same time while looking for a candidate channel...

This would only be possible if device would have two receivers ... or DSP software which would allow receiving whole band at the same time. Radars tend to show as rare really short energy spikes (could be once in 10 minutes) and device needs to dedicate 100% of time to listening the same chunk of spectrum not to miss this spike (it would likely miss it if receiver would switch between multiple channels scanning them). It's very different from scanning for WiFi SSIDs where device receiver can jump over all channels and eventually it detects most of detectable neighbours.

I think it would be welcome if LEDs on WiFi AP would go into some distinct colour/pattern when AP is in DFS listening mode ... I guess people would then less often panick about AP's hardware problem and instead focus on making configuration of their AP more robust.

It would be nice when the AP would make (more) effort to monitor several channels at the same time while looking for a candidate channel...

I think it would be welcome if LEDs on WiFi AP would go into some distinct colour/pattern when AP is in DFS listening mode ... I guess people would then less often panick about AP's hardware problem and instead focus on making configuration of their AP more robust.

Damn... Why didn't anyone think about that earlier ?
Brilliant suggestion !!

I guess you can already script that led disco 🤣

It would be nice when the AP would make (more) effort to monitor several channels at the same time while looking for a candidate channel...

This would only be possible if device would have two receivers ...

But todays devices all have two, three or four receivers!
Whether they can be independently listen on different frequencies, that may be a different matter.

This would only be possible if device would have two receivers ...

But todays devices all have two, three or four receivers!

You know all too well what I meant. And you also know well that chains of a radio (i.e. MIMO legs) are not independent and are not meant to be tuned individually (even if they are made the way it would technically allow that) as they are normally combined in DSP processing.

I'm not so sure about that. E.g. on other manufacturer's equipment, one chain can remain operational while the other scans or surveys the band, monitors neighboring APs, etc.

E.g. on other manufacturer's equipment, one chain can remain operational while the other scans or surveys the band, monitors neighboring APs, etc.

Out of curiosity: what's the price tag of that piece of equipment?

And, unless it's got N+1 receivers (where N is MIMO rank), performance of live connections will drop while doing the other tasks. Yes, in the case we're discussing now (monitoring for radar signals while any transmission is blocked and looking for other feasible channels) this doesn't matter, but still ...

It is only one step up in price category. And you also get sufficient flash for upgrades and partioning so that is not a bad deal.

I'm not so sure about that. E.g. on other manufacturer's equipment, one chain can remain operational while the other scans or surveys the band, monitors neighboring APs, etc.

That is not correct. Regulations direct that after initial Channel Availability Check (that can last anywhere from 1 min up to 10 minutes PER frequency) all equipment, including MikroTik, must do constant In-Service Monitoring (which does not interrupt wifi connections) and if radar pulses are detected must immediately cease operating at current frequency (on all chains) and switch to another which requires new Channel Availability Check phase... depending on the chipset, number of chains and overall number of users companies can choose to do periodic Channel Availability Checks and use data gathered to skip that phase during frequency switching but they cannot continue operating (if radar is detected) on one chain while scanning on the other...

That is not what I am suggesting. What I suggest is that when a radar event has been detected, several channels be monitored at the same time, to more quickly select a new channel with least chance of radar events.
As it is now, when the device experiences radar on channel 100, it will happily switch to 120 and do the check, while in fact the chance of radar on 120 is higher than on 100. Had it tried 108, it would have more chance of a clear channel. But to know that, it can scan several channels in parallel.
(it could also help to, in countries that have different monitoring times for each channel, to first try a channel with a short monitoring time)

So the device itself (cap ax) does not crash - "only" the 5ghz interfaces do not come up again after a DFS event?

No, the device crashes (becomes unresponsive over the network), but only when 5 GHz WiFi is enabled (via CAPsMAN). The only thing that helps is a power cycle. And since it crashes, I cannot say for sure that it is related to DFS, but that seems to be a realistic hypothesis (formulated by MikroTik support).

You could enable logging to disk of wireless events and hope that there still is something logged before it really crashes.

it hAP ac2 in screenshot? doubts

No, screenshots are from Audience (the other half of setup). @OP never claimed they were from hAP ac2.

the old hap-ac2 ran 7.14 with old wireless package which i posted before, now have upgraded few days ago with wifi-qcom-ac package via netinstall
enclosed :
hap-ac2 7.14.3 qcom-ac
Audience 7.14.2 qcom-ac
hap-lite 7.14

On RB5009 with 7.14.3 inter-vlan printing doesn't work. Disabling hardware offload on the bridge or going back to 7.14.2 fixes the problem. Same problem has happened on a previous version with RB750GR3.

Is it possible to be more specific about this printing problem? Does printer appear offline to users (possible problem with SNMP) or is it just jobs failing (print protocol problem)? Does ping from user to printer work?

Can ping the printer, sometimes printer shows online but most of the time offline. Jobs failing and every now and then a job goes through.

Disabling hardware offloading and job queues immediately go out and all documents waiting to print, print correctly.

That is likely something that (also) depends on your particular configuration.

I'll be doing some config test - firewall included, later on. Want to rule out those as well.

But turning hardware-offloading on and off shouldn't change behaviour like that, except when it's a bug.

@seriquiti
Make a new thread and post your config. There are many printing protocols so also post how to you connect to the printer.

Installed update again this morning and all working correctly. Clients printing etc. No config changes....

Was definitely the router because I could make this happen repeatedly by turning hardware offloading on and off repeatedly.

I'm not so sure about that. E.g. on other manufacturer's equipment, one chain can remain operational while the other scans or surveys the band, monitors neighboring APs, etc.

That is not correct. Regulations direct that after initial Channel Availability Check (that can last anywhere from 1 min up to 10 minutes PER frequency) all equipment, including MikroTik, must do constant In-Service Monitoring (which does not interrupt wifi connections) and if radar pulses are detected must immediately cease operating at current frequency (on all chains) and switch to another which requires new Channel Availability Check phase... depending on the chipset, number of chains and overall number of users companies can choose to do periodic Channel Availability Checks and use data gathered to skip that phase during frequency switching but they cannot continue operating (if radar is detected) on one chain while scanning on the other...

Proper hardware has a dedicated radio receiver to do CAC probing and construct available channel list in background. Even TP-Link has "zero-wait-DFS" term in their vocabulary.

With Mikrotik you are stuck with what you have i.e. "radar detection" which sometimes works and sometimes not with you ending up only non-DFS channels available - and this can even happen in places where real radar detections just cannot be a thing (i.e. buildings with metal roof and metal in wall lining) while radar detections do not happen outside of this same building. Or then you put two devices of different model into same room and one gives false radar-detections while other one does not. Off-the-shelf generic hardware has its' limits...

I googled a bit on TP-Link and zero wait DFS. I could not find a list of devices which actually support it. I only found out that Omada AX6000 supports it, and this is a device that obviously costs 260€+. Hmmmmmm, wait a second: can you tell me the price of a CAP AX? And then a device by a competitor device in the CAP AX price range that has this incredibly valuable feature?

Well TP-Link is TP-Link but this is obviously about serious vendors and yes this stuff costs what it costs. It is obvious that you (mostly) get what you pay for. I have one site now with new building full of cap XL ac devices and most of them are able only run on 5180 MHz if you use 80 MHz channel as all else is under DFS and CAC produces "no usable channels" if you try to exclude non-DFS channels from channel list. This means that most of them are only able to work on same channel. There's no way any 5 GHz radar signal can get into the building - and at the same time RBD22UGS-5HPacD2HnD devices right outside of this same building can work on any DFS channel without any "radar detections" (btw "thanks" to Mikrotik for discontinuing these). Only explanation can be that these "detections" in the building are false.

OK will stop this off-topic rant as this is not exactly related to this release.

Mikrotik should update CAPsMAN in the documentation (https://help.mikrotik.com/docs/pages/vi ... Id=1409149) to fit to the new concept RouterOS 7.13+.

Hello. I updated cAP ac from 7.13.5 to 7.14.3 with "wireless" package and lost 5GHz network. 2.4GHz works well. Downgrade to 7.13.5 did not help. What could have happened? Everything seems to be formally enabled (7.13.5 now):

Maybe your AP is waiting for the DFS radar detect to complete. Try setting "skip-dfs-channels" on the AP.

Maybe your AP is waiting for the DFS radar detect to complete. Try setting "skip-dfs-channels" on the AP.

"inter wirel set skip-dfs-channels=all wlan2" ? No effect. :-(

Hm: viewtopic.php?p=669799#p669799
Ok. Then the question is another. Why don't I see the ssid="MT-5.0"?

Is there anything about wlan2 in logs since reboot?

On wlan2's Status tab, what Channel is listed?
Also, does it make a difference if you set the Country parameter for wlan2?

Maybe your AP is waiting for the DFS radar detect to complete. Try setting "skip-dfs-channels" on the AP.

It was a correct guess though. My mistake was that I checked it out a "running" flag instead of check connection. It's strange that it was works with default skip-dfs-channels value. Everybody thanks.