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.
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...
Damn... Why didn't anyone think about that earlier ?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...
But todays devices all have two, three or four receivers!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!This would only be possible if device would have two receivers ...
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...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.
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).So the device itself (cap ax) does not crash - "only" the 5ghz interfaces do not come up again after a DFS event?
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 netinstallit hAP ac2 in screenshot? doubts
No, screenshots are from Audience (the other half of setup). @OP never claimed they were from hAP ac2.
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.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...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.
[admin@MikroTik] > int wirel pr
Flags: X - disabled; R - running
0 R name="wlan1" mtu=1500 l2mtu=1600 mac-address=C4:AD:xx:xx:xx:9E arp=enabled interface-type=IPQ4019 mode=ap-bridge
ssid="MT-2.4" frequency=auto band=2ghz-b/g/n channel-width=20/40mhz-XX secondary-frequency=""
scan-list=default wireless-protocol=802.11 vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none
wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no
1 name="wlan2" mtu=1500 l2mtu=1600 mac-address=C4:AD:xx:xx:xx:9F arp=enabled interface-type=IPQ4019 mode=ap-bridge
ssid="MT-5.0" frequency=auto band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX secondary-frequency=""
scan-list=default wireless-protocol=802.11 vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none
wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no
"inter wirel set skip-dfs-channels=all wlan2" ? No effect. :-(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.Maybe your AP is waiting for the DFS radar detect to complete. Try setting "skip-dfs-channels" on the AP.
Does this solves the OOM panic/non-graceful restart related to queue?*) queue - improved system stability (introduced in v7.6);
For me: YESS!!👍Does this solves the OOM panic/non-graceful restart related to queue?*) queue - improved system stability (introduced in v7.6);
and support tried hard to gaslight me into believing that its either a configuration problem or user errorFor me: YESS!!👍
Does this solves the OOM panic/non-graceful restart related to queue?