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?
Thanks!Which packages do you have installed ?
Should be routeros and wifi-qcom, nothing else (provided you have no other things installed on there).
max-entries: Note that the system does not create a maximum-size connection tracking table when it starts, it may increase if the situation demands it and the system still has free RAM, but the size will not exceed 1048576
So does this means that ROS cannot handle more than 1048576 connections?max-entries: Note that the system does not create a maximum-size connection tracking table when it starts, it may increase if the situation demands it and the system still has free RAM, but the size will not exceed 1048576
It's calculated max-entries can be shown via:That's a 20-bit number (1 and then 20 0's) ... looks like something hardcoded.
/ip/firewall/connection/tracking> pri
enabled: auto
active-ipv4: yes
active-ipv6: no
tcp-syn-sent-timeout: 5s
tcp-syn-received-timeout: 5s
tcp-established-timeout: 1d
tcp-fin-wait-timeout: 10s
tcp-close-wait-timeout: 10s
tcp-last-ack-timeout: 10s
tcp-time-wait-timeout: 10s
tcp-close-timeout: 10s
tcp-max-retrans-timeout: 5m
tcp-unacked-timeout: 5m
loose-tcp-tracking: yes
udp-timeout: 10s
udp-stream-timeout: 3m
icmp-timeout: 10s
generic-timeout: 10m
max-entries: 1048576
total-entries: 40798
I see no reason to limit this. If the system needs it, it needs it. If the memory needed is bigger than the memory available, then is time to either change the usage or buy something bigger. Of course, the router should protect itself - the memory usage would be dynamic, but the usage shouldn't grow past (say) 80% of available memory. AVAILABLE memory, not installed memory.Probably this limit was invented 10 years ago and with todays hardware it could well be higher.
Maybe better would be to make this property settable and have the user decide how much RAM they want to spend on connection tracking...
i agree with thatReduce the established to 1h, and increase the udp from 10 to 30 sec
That should remove the issue.
It is no sense nowadays to have 1d established timer.
A reason to limit it is that when there are more entries, the CPU load to search them would also be higher.I see no reason to limit this. If the system needs it, it needs it. If the memory needed is bigger than the memory available, then is time to either change the usage or buy something bigger.Probably this limit was invented 10 years ago and with todays hardware it could well be higher.
Maybe better would be to make this property settable and have the user decide how much RAM they want to spend on connection tracking...
Ok, I should've been more clear.A reason to limit it is that when there are more entries, the CPU load to search them would also be higher.