5GHz channels disappeared on hAP ax2

robmaltsystems · Wed Jan 10, 2024 2:30 pm

I'm starting to despair with Mikrotik Wi-Fi. Yeah, yeah I know - why do I even persist as it really is their weak point

I wanted to get some experience of RouterOS v7 and Wi-Fi 6 so I bought a hAP ax2 before Christmas to use at home on my dev network. I've gone from never having to worry about the Virgin Media SuperHub to seeming to have Winbox open all the time! You wouldn't expect VM to get praise!

Today's problem - latest version v7.13 and I wondered why my laptop seemed to be very slow transferring an ISO. Checked Wi-Fi and it's connected at 2.4GHz. Now this does sometimes happens with Windows so I turned Wi-Fi back off and on, sat 2m from the router. No difference. Brought up Wi-Fi analyser on my mobile and the 5GHz channels have totally disappeared. Just the distant neighbours Virgin Media SuperHub:

I disabled and re-enabled the wireless interfaces (I have a private LAN and guest VLAN) and it's come back:

I see there are quite a few posts about problems with Mikrotik AX

Anything obvious to try? At a clients site, the cap AC access points have to be rebooted every night to maintain a stable system...

whatever · Wed Jan 10, 2024 2:33 pm

Check log for radar detection / DFS events. Do you have non-DFS channels configured as well?

robmaltsystems · Wed Jan 10, 2024 3:37 pm

I'll check the logs but as I rebooted it about 5 mins ago, I've lost overnight. Can the logs be written to a syslog server? The AX2 doesn't have a USB socket so can't write them to a pen drive.

Even if there was a radar/DFS event, as it's currently configured for auto, shouldn't it move to another channel if a conflict popped up?

whatever · Wed Jan 10, 2024 3:45 pm

If another frequency is available, then it should switch channels on DFS events, yes. That's why I was asking. Maybe just set channel to 5180 and check if it still disappears.

robmaltsystems · Wed Jan 10, 2024 5:21 pm

Maybe just set channel to 5180

Good idea - that will isolate whether it's software or hardware related.

mkx · Wed Jan 10, 2024 8:47 pm

Another possibility when device is set to default (wide) frequency range: hAP ax2 chooses to use one of U-NII3 channels which are not supported by not-so-recent wireless devices.

robmaltsystems · Thu Jan 11, 2024 1:14 pm

It had gone again this morning but I've had to come out so no chance to diagnose further. The only change I made yesterday was changing the SSID to distinguish between the 2.4GHz and 5GHz channels. 2.4GHz still working fine. Later...

I'll share the configuration later once I've read through it myself.

bpwl · Thu Jan 11, 2024 2:24 pm

Another possibility when device is set to default (wide) frequency range: hAP ax2 chooses to use one of U-NII3 channels which are not supported by not-so-recent wireless devices.

Yes, got me surprised with my first ax(2) device. Quite a wide range in 5GHz, probably not supported by my PC (it has an ax wifi card (MediaTek Wi-Fi 6 MT7921 Wireless LAN Card)), or only at low power. Those frequencies are new to me as well. viewtopic.php?t=202544#p1047708

Use CLI command "/interface/wifiwave2/radio> print detail" and see what freq you can get for your country as it is set.
Wifi1 interface status showed it used the high upper range (5865) , out of the box.

EDIT EDIT EDIT

And I learned later that ....
- all above 5700MHz in Europe is max EIRP level of only 14dBm (16dBm below that of the lower frequencies)
- default country (none set) changed in ROS 7.13.1 to Latvia (that has those low ETSI/Europe EIRP levels)
- the hAP ax prefers those high freq if not told otherwise
- the hAP ax2 disappeared from my test devices, because the signal was way too weak

robmaltsystems · Thu Jan 11, 2024 3:09 pm

Back home. The automatic frequency chosen is 5720/ax/eeeC (DFS). I assume that means it's operating in these channels:

Now here is where it gets interesting... my Xiaomi Redmi Note 12 can't see the 5GHz Wi-Fi network at all but a Lenovo laptop that I happen to have on the bench is connected to the 5G network fine.

Notes on the phone: it's new and is the only device I've got that supports Wi-Fi 6. It can certainly operate on channels 132-144. It can also use channels 149 upwards which sometimes.

The eeeC bit is interesting... I asked on another post about how you configured sidebands on ROS7/Wave2 as the user interface is different to ROS6. In ROS6, you can pick Ceee, eCee, eeCe and eeeC. I can't see how do that with ROS7. I was told you can put 5180 in frequency and that indeed works - but forcing Ceee. I wonder if I put 5200 in there that I'd get eCee?

I'm just about to force 5180 and see how it is for a few days.

robmaltsystems · Thu Jan 11, 2024 3:15 pm

I was told you can put 5180 in frequency and that indeed works - but forcing Ceee. I wonder if I put 5200 in there that I'd get eCee?

Immediate follow-up, yes this is indeed how it works. Consider this part of the spectrum:

5180 - Ceee
5200 - eCee
5220 - eeCe
5240 - eeeC

robmaltsystems · Thu Jan 11, 2024 6:29 pm

I was working through the various channels, testing each one with my mobile and on 5680, it started working and then said "failed to select channel"

And a key entry in the log: private-5g: radar detected on 5680/ax/eCee. This isn't always occurring butt might start to give some hint as to what's going on. If there are radar events (unusual, never seen before here but who knows), shouldn't the router try and find a different frequency when the frequency is set to blank/auto?

This is the result of testing with my laptop and Android mobile:

5180/ax/Ceee OK
5200/ax/eCee OK
5220/ax/eeCe OK
5240/ax/eeeC OK

5660/ax/Ceee OK
5680/ax/eCee OK
5700/ax/eeCe OK
5720/ax/eeeC FAILED

The mobile is unable to connect on that very last configuration which happens to be the one that auto keeps favouring. Now I know I can set the frequency manually, I'm more intrigued here why the mobile (and it happens my Android tablet) struggles with that particular configuration. Because it's not the range 5650-5730 as such as 5660 works. It's when the control channel is on 5720. Probably not Wi-Fi 6 chipset in mobile either as Wi-Fi 5 tablet struggles too.

I dropped the channel width down to 20MHz and went through 5660, 5680, 5700 and 5720. It's the last one that's problematic for sure. Could connect (mobile & tablet) on the first three but not last. Once again, laptop fine on all of them.

I'm going to dig out an AC router which I think I've got in the box and have a play on that.

robmaltsystems · Thu Jan 11, 2024 7:51 pm

Interesting read once I isolated the problem:

https://www.emperorwifi.com/2015/09/the ... l-144.html

"Channel 144 (5.720 GHz) is a 20 MHz channel that is a part of the UNII-2e band. It was added in March 2014 specifically as part of the official 802.11ac specification, so that the new Wi-Fi amendment would support an additional 80 MHz channel of 132-144 (see the figure above)."

"What this means in practice is that you can ONLY use channel 144 as part of an 80 MHz channel, and must use the Upper Extension (or Upper / Upper or Upper / Lower), so that 40 MHz and 20 MHz legacy clients would avoid the use of Channel 144".

And another post: https://support.accessagility.com/hc/channel-144. Although surprised a 2023 mobile phone has this problem. My Far East tablet is more understandable.

IMO I think ROS should avoid 5720/ax/eeeC for this reason.

robmaltsystems · Thu Jan 11, 2024 9:27 pm

Putting this one to bed for now. I've repeated the problem on a hAP AC lite. If channel 144 is used as the control/main channel, then some devices are unable to connect. Not specifically older devices either. My XiaomiRedmi Note 12 Pro 5G was released less than a year ago and it has the same problem.

IMO ROS should avoid channel 144 as the control channel (5720/ax/eeeC) for this reason. In auto mode, it should also really avoid channel 149 and above as well as that's got problems with some devices.

Of course, one should probably avoid auto entirely and pick a channel after a site scan. However, this isn't always perfect if other access points are around on auto and hop onto the carefully chosen channel.

robmaltsystems · Mon Jan 29, 2024 12:44 pm

Back from a week's holiday and the 5GHz interface has disappeared again. Disabling and re-enabling the 5GHz wireless interfaces gets it back. I might script that each night. Certainly something amiss. The 2GHz interface is fine. I notice there has been an update since I've been away so fingers crossed only "wifi-qcom" seems vaguely related to this.

infabo · Mon Jan 29, 2024 1:06 pm

You should check the logs and/or winbox wifi-tab and/or the output of "/interface/wifi/print detail" (which should show interface-errors as comments in output).

There must be a reason why 5ghz is down. Of course you can disable/enable to get it up again. But then you can't inspect the "non working state" anymore.

If you are sure this is not a config issue (we can't judge on this, because you did not post your config here), you can create a supout.rif once 5ghz is non-working again. Toggle 5ghz interface to get it running again. Then create another supout.rif. Send these 2 files to MT support and let them inspect.

robmaltsystems · Mon Jan 29, 2024 1:31 pm

# 2024-01-29 11:29:04 by RouterOS 7.13.3
# software id = 8SND-BECL
#
# model = C52iG-5HaxD2HaxD
# serial number = HE508WV8MKT
/interface bridge
add admin-mac=48:A9:8A:64:E9:B4 auto-mac=no comment=defconf name=bridge \
    port-cost-mode=short
/interface vlan
add interface=bridge name=guest-vlan vlan-id=10
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=VLAN
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no name=middle-earth
add authentication-types=wpa2-psk,wpa3-psk disabled=no name=shire
add disabled=no name=open
/interface wifi
set [ find default-name=wifi2 ] channel.band=2ghz-ax .skip-dfs-channels=\
    10min-cac .width=20/40mhz configuration.country="United Kingdom" .mode=ap \
    .ssid="Middle Earth" disabled=no name=private-2g security=middle-earth
set [ find default-name=wifi1 ] channel.band=5ghz-ax .frequency=5500 \
    .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.country=\
    "United Kingdom" .mode=ap .ssid="Middle Earth 5G" disabled=no name=\
    private-5g security=middle-earth
add configuration.mode=ap .ssid="The Shire" datapath.vlan-id=10 disabled=no \
    mac-address=4A:A9:8A:64:E9:B9 master-interface=private-2g name=guest-2g \
    security=shire
add configuration.mode=ap .ssid="The Shire" datapath.vlan-id=10 disabled=no \
    mac-address=4A:A9:8A:64:E9:B8 master-interface=private-5g name=guest-5g \
    security=shire
/ip pool
add name=guest ranges=10.0.0.10-10.0.0.254
/ip dhcp-server
add address-pool=guest interface=guest-vlan lease-time=2h name=guest
/system logging action
set 3 remote=192.168.0.7
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=ether3 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=ether4 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=ether5 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=private-5g internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=private-2g internal-path-cost=10 \
    path-cost=10
add bridge=bridge interface=guest-2g internal-path-cost=10 path-cost=10
add bridge=bridge interface=guest-5g internal-path-cost=10 path-cost=10
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface detect-internet
set detect-interface-list=all
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=guest-vlan list=VLAN
/interface wifi access-list
add action=accept comment="Frodo 5G" disabled=no mac-address=\
    00:45:E2:81:E4:61
add action=accept comment="Treebeard 2G" disabled=no mac-address=\
    1C:BF:CE:4D:15:52
add action=accept comment=Mobile disabled=no mac-address=56:95:CC:AA:40:9F
add action=accept comment=Mobile disabled=no mac-address=02:53:E4:D5:F1:16
add action=accept comment=Helmsdeep disabled=no mac-address=5C:E0:C5:E3:E1:99
add action=accept comment="Epson printer" disabled=no mac-address=\
    38:1A:52:18:30:36
add action=accept comment="Echo Dot" disabled=no mac-address=\
    74:E2:0C:AC:E4:4A
add action=accept comment="Heater smart plug" disabled=no mac-address=\
    FC:67:1F:B8:B7:88
add action=accept comment=Tablet disabled=no mac-address=02:C5:0B:DD:34:CF
/ip address
add address=192.168.0.1/24 comment=defconf interface=bridge network=\
    192.168.0.0
add address=10.0.0.1/24 interface=guest-vlan network=10.0.0.0
/ip dhcp-client
add comment="Virgin Media modem WAN" interface=ether1
/ip dhcp-server network
add address=10.0.0.0/24 dns-server=1.1.1.1,8.8.8.8 gateway=10.0.0.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.0.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="Accept established,related,untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="Drop invalid packets" connection-state=\
    invalid
add action=accept chain=input comment="Accept ICMP (ping)" protocol=icmp
add action=accept chain=input comment=\
    "Accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input disabled=yes in-interface-list=VLAN
add action=drop chain=input comment="Only allow access to router from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="Accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="Accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=\
    "Fasttrack existing connections through firewall (no rules applied)" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "Accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
add action=drop chain=forward comment=\
    "Drop all from WAN not DSTNATed (block incoming connections)" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="Default NAT out" ipsec-policy=\
    out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port forward SimpleHelp TCP" \
    dst-port=8008 in-interface-list=WAN protocol=tcp to-addresses=192.168.0.7 \
    to-ports=8008
add action=dst-nat chain=dstnat comment="Port forward SimpleHelp UDP" \
    dst-port=8008 in-interface-list=WAN protocol=udp to-addresses=192.168.0.7 \
    to-ports=8008
add action=dst-nat chain=dstnat comment="Port forward HTTP" dst-port=80 \
    in-interface-list=WAN protocol=tcp to-addresses=192.168.0.14 to-ports=80
add action=dst-nat chain=dstnat comment="Port forward HTTPS" dst-port=443 \
    in-interface-list=WAN protocol=tcp to-addresses=192.168.0.14 to-ports=443
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/London
/system identity
set name=ROUTER001
/system logging
set 0 action=remote
set 1 action=remote
set 2 action=remote
set 3 action=remote
add action=remote topics=debug
add action=remote topics=wireless
/system note
set show-at-login=no
/tool graphing interface
add interface=ether1
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

robmaltsystems · Mon Jan 29, 2024 1:33 pm

It's a pretty standard configuration. Only significant additional configuration over basic router configuration is setting up of a guest VLAN and some port forwarding. The 5GHz frequency is set to 5500 to get maximum Tx power.

Logging is going to Kiwi syslog server free running on my Windows server. Might install a Linux syslog server as I can't work out how to filter in the free version of Kiwi.

robmaltsystems · Mon Jan 29, 2024 3:16 pm

Bad blocks of 0.1% is a little unexpected?

[admin@ROUTER001] > /system/resource/print
                   uptime: 2h1m14s
                  version: 7.13.3 (stable)
               build-time: Jan/24/2024 13:16:46
         factory-software: 7.5
              free-memory: 648.9MiB
             total-memory: 960.0MiB
                      cpu: ARM64
                cpu-count: 4
            cpu-frequency: 864MHz
                 cpu-load: 1%
           free-hdd-space: 93.8MiB
          total-hdd-space: 128.0MiB
  write-sect-since-reboot: 728
         write-sect-total: 674230
               bad-blocks: 0.1%
        architecture-name: arm64
               board-name: hAP ax^2
                 platform: MikroTik

Mon Jan 29, 2024 3:51 pm

Bad blocks of 0.1% is a little unexpected?

Not really. Sooner or later EVERY flash device will have some bad blocks.
As long as it doesn't increase on a short timeframe, nothing to worry about.

gotsprings · Mon Jan 29, 2024 4:23 pm

It's a pretty standard configuration. Only significant additional configuration over basic router configuration is setting up of a guest VLAN and some port forwarding. The 5GHz frequency is set to 5500 to get maximum Tx power.

Logging is going to Kiwi syslog server free running on my Windows server. Might install a Linux syslog server as I can't work out how to filter in the free version of Kiwi.

Everytime I see your avatar I think about the apologists.

infabo · Mon Jan 29, 2024 4:27 pm

The most likely explanation is that the "private-5g" interface goes down due to a detected radar signal. Since the frequency is fixed at 5500, ROS cannot switch to a non-DFS channel. It has to wait for 30 minutes, after which it should perform a CAC. If the check is okay, the interface goes back online. There might be an issue with ROS in handling this operation. But you should see according entries in log and/or interface.

Other remarks:

1) I would not explicitly set ".width=20/40/80mhz" or "20/40mhz". These look like the hardware defaults anyway. Just unset these values, so the driver can choose the "maximum supported by hardware".
2) you'd probably specify a list of frequencies if you like to use DFS-channels only. So in case of radar signal ROS can switch to another channel.

bpwl · Mon Jan 29, 2024 6:38 pm

t has to wait for 30 minutes

Wow ..

But everyone says it differently, all vendors implement it differently?

30 minutes to return back to the first frequency.
CAC of 1 min or 10min CAC is known.
30 minutes ? Seriously if only one DFS channel available?

https://documentation.meraki.com/MR/Rad ... FS_Actions
https://www.wifi-professionals.com/2023 ... -detection

EDIT
and another variation: https://www.clearcom.com/DownloadCenter ... annels.htm
What is the MT case ???

infabo · Mon Jan 29, 2024 7:05 pm

I possibly depends on the regulation - not the vendor.

I found this document for ETSI saying:

Non-Occupancy Period 30 minutes

Look yourself:

ETSI: https://www.etsi.org/deliver/etsi_en/30 ... 20101p.pdf

Another resource: https://mum.mikrotik.com//presentations ... 299009.pdf
slides 70 and 76 mention the non-occupancy period of 30 minutes.

In my understanding non-occupancy period means: once there is radar detected on frequency 5500 the device is not allowed to use this channel for at least 30 minutes. The device can switch to another channel immediately once radar is detected - adhering the normal CAC checks.

So if the user does not restrict frequencies:

- channel 100 used (5500)
- radar detected on 5500
- AP decides to either switch to a non-DFS one or a CAC-one and announces the new channel to its clients. In case of non-DFS it is like immediately or 1min/10min for non-DFS depending on the channel and regulation.

But OP restricted the channel to 5500 only. So 5ghz is down for at least 30min. But should be available after this period.

Mon Jan 29, 2024 7:59 pm

If no other detection is done in between...

Santi70 · Mon Jan 29, 2024 11:23 pm

That's the theory, neither of the two cases has worked for me.
1- When I put only one DFS channel, it stopped transmitting and I got an error, no channels available and it never transmitted again until I disabled and enabled it again.
2- DFS channel with another NO DFS, stopped transmitting and did NOT give any error nor did it transmit on the backup NO DFS channel nor did it transmit again until I disabled it and re-enabled it.

infabo · Tue Jan 30, 2024 1:00 am

Santi70, you should report this to MT support directly. This needs investigation.

robmaltsystems · Tue Jan 30, 2024 2:12 am

The most likely explanation is that the "private-5g" interface goes down due to a detected radar signal. Since the frequency is fixed at 5500, ROS cannot switch to a non-DFS channel. It has to wait for 30 minutes, after which it should perform a CAC. If the check is okay, the interface goes back online. There might be an issue with ROS in handling this operation.

If it is detecting a radar event, then I don't think the coming back online is working - it never comes back even after 30 minutes. I'll do some more tests if it happens again.

But you should see according entries in log and/or interface.

I've never seen anything DFS or CAC related in the logs. Do I need to enable some additional logging?

1) I would not explicitly set ".width=20/40/80mhz" or "20/40mhz". These look like the hardware defaults anyway. Just unset these values, so the driver can choose the "maximum supported by hardware".

This was set by the default configuration but I've removed them anyway.

2) you'd probably specify a list of frequencies if you like to use DFS-channels only. So in case of radar signal ROS can switch to another channel.

Do you add these as additional frequencies under Frequency or use Secondary Frequency?

robmaltsystems · Tue Jan 30, 2024 2:16 am

I got an error, no channels available

Just for the record, I've never seen an error like this. If always comes online after the 1 minute radar check. Although the sequence of events that Santi70 describes does sound very similar. Leave the router for a period of time and the 5GHz interface isn't accessible by any device. Until I restart the router or disable/enable the 5GHz interface.

robmaltsystems · Tue Jan 30, 2024 2:33 am

https://www.wifi-professionals.com/2023 ... -detection

Interesting read that suggests that DFS isn't just about radar detection. I did used to assume that you should leave channel selection on auto and let the device find the best 5GHz channel. Continually monitoring the spectrum and moving if there was a better channel. But on my ax2 that presented four problems:

It can choose channel 144 as the control channel (eeeC) which doesn't work on some devices, specifically my new-ish mobile. See https://www.emperorwifi.com/2015/09/the ... l-144.html
Secondly, it can choose channel 149+ which doesn't work on my cheap Android tablet due to 802.11d quirks, i.e. my tablet won't use 149+ channels as it doesn't know it's in the UK. Although I assume I could fix this by limiting the frequency range? How do you do that on ROS 7? It's a different interface to ROS 6
I'd really like to use 5500 as a) nobody else around me it using it and b) it's got the best Tx power in the UK - about -10db better than channel 36/5120MHz
It never seemed to change channel after the initial selection, i.e. it isn't continually monitoring the spectrum. So if another transmitter popped up on the same channel, you got a clash.

Tue Jan 30, 2024 6:00 am

Do you add these as additional frequencies under Frequency or use Secondary Frequency?

Frequency.

robmaltsystems · Tue Jan 30, 2024 11:31 am

An aside, but UBNT access points certainly change channels to avoid interference as spotted this in the logs:

There really does seem to be conflicting advise around this whole area!

infabo · Tue Jan 30, 2024 11:43 am

That log entries from UBNT are IMHO not related to radar. It is a functionality that AFAIK Mikrotik has not implemented (I am not sure on that).

Most other vendors, like Unifi APs, scan the spectrum for interference. Meaning either microwave interference on 2ghz or interference with other AP sending on same channel or overlapping channels. Once they detect such, they change channel. Never seen that on my MT (nor on legacy wireless nor on qcom-wifi). MT selects a channel when in auto mode and stays on the channel forever (or reboot or disable/enable interface).

infabo · Tue Jan 30, 2024 10:44 pm

Could be related: viewtopic.php?p=1052817

robmaltsystems · Tue Jan 30, 2024 11:23 pm

That log entries from UBNT are IMHO not related to radar. It is a functionality that AFAIK Mikrotik has not implemented (I am not sure on that).

Linking back to an article shared above: https://www.wifi-professionals.com/2023 ... -detection

The interesting bit is that DFS is not just about radar detection. The name dynamic frequency selection gives a clue to it's wider use- radar detection being just one part of DFS. Another part is Dynamic Channel Switching:

If the CAC reveals the presence of radar signals, DFS facilitates dynamic channel switching. In this scenario, Wi-Fi devices swiftly vacate the affected channel and transition to another deemed clear of radar activity. This automatic adjustment minimizes interference and ensures seamless network operation.

So UBNT does this:

DFS isn’t exclusive to radar scenarios. It’s equally essential in managing channel selection in the absence of radar signals. This becomes particularly crucial in densely populated areas where multiple Wi-Fi networks operate concurrently. DFS enables networks to dynamically adjust their channels, optimizing performance and minimizing interference.

If RouterOS is able to detect radar and move to another channel, it could equally use the same technology to avoid other access points. It clearly does some analysis where the frequency isn't defined - it finds a channel. However, what I'm not sure RouterOS is continually monitor the channel to see if another access point barges in.

So what's happening to me is either (a) a bug whereby the 5Ghz channel just shuts down or (b) radar is detected a long time after power-up (weird as unlikely around here) and because I've only got 5500 defined, it turns the 5Ghz channel off.

I've yet to try adding a secondary frequency.

This is a classic example where input from the coder would answer how it's designed to work.

robmaltsystems · Tue Jan 30, 2024 11:50 pm

It's disappeared again but this time, I'm seeing this error. There is nothing written to the log though. Anyone any idea what the log message should be so I can filter?

I assume this means a radar event has occurred? There is nothing in the log. I'm just about to add 5180 as another frequency.

Later... frequency is now set as this. Will see what happens overnight. It's done the radar check and found 5500 is okay with Tx power 25... at the moment.

bpwl · Wed Jan 31, 2024 1:54 am

Don't know if this will help here, but for more logs on wireless (eg. attemps to associate with WLAN driver) one needs topics "wireless,debug". Additional lines will be in the log then, which only contained "wireless,info" ( e.g. connected/disconnected) before.

robmaltsystems · Wed Jan 31, 2024 12:42 pm

Thanks for that - never 100% sure how the log rules work with debug. This is what I've currently got:

There is no specific mention of debug but I am getting wireless, debug lines in the log:

BTW - those connection rejected lines are because I spotted one of my elderly neighbour's devices (I share a VLAN with them) was continually attempting to connect to Wi-Fi and failing. So I've added that rule and have asked them to tell me which device has stopped working

PS. 5G interface on channel 5500 still there this morning...

robmaltsystems · Thu Feb 01, 2024 9:54 pm

Update on this issue... recall that my router is now configured with 5500, 5180 in the frequency box. At 10:20 this morning, radar was detected on 5500. Let's put aside why a radar event was detected over 24 hours since 5500 was chosen. The router has switched to 5180. Does anyone else think that it should have switched back to 5500 at some point?

IMO any advice about specifying the frequency manually where a DFS channel is used should also say add 5180 (non-DFS). My experience so far is that if you have 5500 alone (DFS in UK and often chosen as max Tx power) and a radar event is detected, the 5GHz channel shuts down entirely. I would argue that this is a bug in ROS 7 - if a manual frequency has been specified and a radar event is detected later on, it should use DFS to find another channel. Not disable 5GHz entirely?

I've deployed quite a few cAP ac devices and in very busy environments, I've chosen the channels manually. I need to go back to one particularly where "slow speeds" are reported and I wonder this is caused by exactly the same problem on ROS v6? At this site, the cAPs reboot every night. I need to look in the logs for radar events.

Santi70 · Thu Feb 01, 2024 10:11 pm

You were lucky, I have it with 5660, 5220, the first DFS, the second not, with a channel width of 40 MHz, when it detected the radar, it stopped transmitting and did not raise the 5220, nor did it give an error, I'm waiting to see if it happens again

infabo · Thu Feb 01, 2024 10:24 pm

My experience so far is that if you have 5500 alone (DFS in UK and often chosen as max Tx power) and a radar event is detected, the 5GHz channel shuts down entirely. I would argue that this is a bug in ROS 7 - if a manual frequency has been specified and a radar event is detected later on, it should use DFS to find another channel. Not disable 5GHz entirely?

You set frequency=5500 this is a restriction and not a "maybe if you, beloved ROS, like you maybe can prefer 5500 but can fallback to any other frequency if you like".

Read it as: "5500 and nothing else"

robmaltsystems · Thu Feb 01, 2024 11:22 pm

Read it as: "5500 and nothing else"

Well I would say this is a bad design. I regularly specify the channel on UBNT AirMax devices (point-to-point). In fact, recent Nanostation firmware doesn't even have an auto option - you have to pick a channel:

I have never come across a situation where the 5GHz channel simply shuts down because of a (new) radar event. One of my clients using these is right next to Manchester airport (can't hear yourself when a plane goes over) and the four P2P bridges they have are 100% rock solid. I think we'd spot if a radar event occurred and the wireless bridge shutdown.

In addition, I can recall quite a bit of advice on here recommending configuring the channel but I can't recall any discussion about adding a backup channel in case the DFS channel detects a radar event?

I'm going to try a different tack - I've changed the frequency to 5180-5700. It's fortunately (!) chosen the 5500 frequency after doing CAC. Will see what happens over the next few days.

robmaltsystems · Thu Feb 01, 2024 11:30 pm

Read it as: "5500 and nothing else"

Does it work this way on ROS v6 as well? Might explain why one very busy (congestion wise) client I have regularly reported slow Wi-Fi. CAPsMAN is configured there to assign the access points to specific channels. If the same problem is occurring, it might explain the slow down if the 5GHz channels on the APs using DFS specific channels are randomly shutting down because there is a radar event. Also explains why rebooting the access points each night helped as it's never reported a radar event at start-up. I'm going to watch the logs more carefully.

Thu Feb 01, 2024 11:32 pm

Read it as: "5500 and nothing else"
Does it work this way on ROS v6 as well?

Yes it does.

robmaltsystems · Thu Feb 01, 2024 11:47 pm

Does it work this way on ROS v6 as well?
Yes it does.

Somebody else mentioned this above but isn't this a bug in ROS then? As far as I can tell, this is the specification:

The DFS requirements say that the APs mustn't switch back in 30 minutes after detection (known as NOP or Non-Occupancy Period).

So shouldn't ROS disable the 5GHz interface, wait 30 minutes and then try again? As I've never had a "Channel not available" message when resetting the interface, then radar events are rare around here. Not sure what kind of things using radar?

bpwl · Fri Feb 02, 2024 1:29 am

As already mentioned elsewhere viewtopic.php?t=203251&#p1052572 , my perception is that others do implement DFS differently.
I don't have the devices, only see their documentation.
So e.g. Cisco Meraki ...

DFS events can cause an Access Point to use a channel, temporarily, even though that channel has been excluded from use in the Dashboard

4. Access Point selects a different channel permitted within the regulatory domain.  (DFS events can cause an Access Point to use a channel, temporarily, even though that channel has been excluded from use in the Dashboard.  Should this behavior prove problematic, contact Cisco Meraki Support to set a specific channel to switch to, in the case of DFS events.)

bpwl · Fri Feb 02, 2024 1:35 am

Not sure what kind of things using radar?

Many problems in my setups where wAP ac's are generating false positive radar patterns for SXTsq unintentionally pointing at them.
viewtopic.php?t=186707&#p994863
Even seeing phantom wAP ac frequencies in that case. viewtopic.php?t=168419

robmaltsystems · Fri Feb 02, 2024 2:27 am

I guess there could be radar around my house but I'd be surprised if there was. I live in an old mill town cottage with really thick walls. Mobile signal is pretty dire - so bad that my mobile usually uses Wi-Fi calling. I'm also convinced my new Xiaomi Redmi Note 12 isn't helping either - I've currently got two hAP ac's on the bench documenting CAPsMAN. They're broadcasting SSIDs called "Test 2G" and "Test 5G". Very often when I go into Wi-Fi Analyser on my mobile and the 5G channel isn't there. Turn Wi-Fi off and on and it re-appears. They're already there on my old Android tablet.

Just done it again! "Test 5G" disappeared as I was looking at Wi-Fi analyser...

Doing my head in for one night!!!

infabo · Fri Feb 02, 2024 10:08 am

Running the old wireless drivers, the event of enabling wifi on my Huawei tablet caused a radar detection on the AP.

robmaltsystems · Sat Feb 03, 2024 1:42 pm

Before I go barging in with a support ticket, I'd like to discuss hypothetically some more as to how "we" expect this to work. This morning I've come to a radar event in the log, "failed to select channel" and no 5GHz interface:

The interface is configured with a single 5500 frequency setting. Observation is that during this post and the many times I've caused the CAC check to kick in, I've never seen this failure during initial enabling of the interface. The radar events have always occurred randomly many hours later. It is possible that this is a fake radar event but we'll park that for now and assume it's a real event.

There are lots of questions here...

Should the advice be to not use specific frequencies at all and leave this field blank? This goes against a lot of advice to do a scan and pick a specific frequency range
What about 5660/eeeC and issues with channel 144 as the control channel on some (modern) devices?
Some devices can't connect to 5GHz with channels 149 and above. Given this and above, should you program frequency as 5180, 5260, 5500, 5580, 5660 to ensure it's usable by most devices?
If you specified 5500 first in the list, would it prefer that frequency? It's the max Tx power in the UK.
If you specified 5500, 5180 as the frequencies and a future radar event is detected on 5500, it does switch to 5180. However, according to DFS specification that 5500 channel is only blocked for 30 minutes. Is it reasonable to expect ROS to try the channel selection again after 30 minutes starting with 5500 and choosing that again if no radar events are detected?
If 5500 is the only frequency specified and a future radar event is detected on that channel, do you think ROS should fallback to automatic scanning mode and find another channel. But once again, after 30 minutes, check 5500 for radar again and if not detected, switch back? Or is the current design of turning off the 5GHz interface acceptable? (I don't)
Does the ROS auto channel selection process only trigger when the interface first comes up or a radar event is detected? Should it periodically do a scan to make sure the channel hasn't become congested and there is a better channel to use? Like the Ubiquiti UniFi devices do. ROS clearly has the basic functionality for this, i.e. scan and channel switch - as it uses it during a radar event.
Is the entire 5GHz channel and DFS a right mess?

Sat Feb 03, 2024 1:47 pm

My (perhaps controversial) view:
why keep insisting on using frequency ranges for which you KNOW in advance you will come into trouble, you simply don't know when.

I avoid DFS ranges. No problems.

robmaltsystems · Sat Feb 03, 2024 2:04 pm

I avoid DFS ranges. No problems.

I can relate to that but in the UK that effectively means you have one 80MHz range 5170-5250. This means that congestion and Tx power become considerations. In the UK, this range has power of 18db on my test hAP ax2. This is significantly less than 5490-5570 which is 25db. The other non-DFS choices of 5735 and above are even worse with Tx power of 9db plus not usable by some client devices.

robmaltsystems · Sat Feb 03, 2024 2:09 pm

At the risk of teaching granny to suck eggs, but in situations like this, I switch to my developer hat and consider the basic framework of how I'd tackle it. Totally appreciate this is very simplistic and there are a LOT of edge cases to consider.

BEGIN frequency selection
FOR EACH frequency in list DO
	IF frequency currently not in 30 minute CAC block THEN
		Carry out CAC check
		IF no radar THEN
			Select frequency/switch
			EXIT FOR
		ENDIF
		Mark frequency as in 30 minute CAC block
	ENDIF
NEXT frequency
Carry out entire spectrum scan for best frequency
END

BEGIN radar event
Mark frequency as in 30 minute CAC block
Perform frequency selection again
END

BEGIN end of 30 minute CAC block
Perform frequency selection again
END

As far as I can tell, the "Frequency selection" block is very close to what it currently does with the exception of the "Carry out entire spectrum scan for best frequency" - difficult to verify as radar event never occurs during first enabling of interface. What I don't see any evidence of is the end of 30 minute CAC block selection occurring again. With 5500, 5180 it appears to failover to 5180 but never switch back to 5500 after 30 minutes.

ToTheFull · Sat Feb 03, 2024 2:37 pm

I avoid DFS ranges. No problems.
I can relate to that but in the UK that effectively means you have one 80MHz range 5170-5250. This means that congestion and Tx power become considerations. In the UK, this range has power of 18db on my test hAP ax2. This is significantly less than 5490-5570 which is 25db. The other non-DFS choices of 5735 and above are even worse with Tx power of 9db plus not usable by some client devices.

I'm about 15 months ahead with a Hap AX2 and Cap AX, UK based and can relate to a lot of what you are now calling out.
Even tried to get the upper frequency power levels changed but sadly Mikrotik don't appear to want to change the power levels for the upper frequencys to solve some of the problems you are having with Radar etc. Have a look here viewtopic.php?t=200330 it should be 200mw for the Uk 5745-5805 not 20mw which would give another 80-wide option none dfs. Also a quote in the above thread even says that Ubquiti products in the uk give 200mw for those frequencys.
Reference for output power.... https://fccid.io/TV7C52-5AXD2AXD

robmaltsystems · Wed Feb 07, 2024 12:35 am

Bit more supplemental information here. Another radar event occurred tonight at 20:27 on 5500 when I happened to be looking. Frequency currently set to 5500, 5580, 5660 and 5180. Caught it doing a 10 min CAC on 5580 so it does work through the frequencies during a radar event. It then stayed on 5580.

I've currently got a schedule task running every hour which restarts the interface so at 21:00 it switched back to 5500. Bit of a fudge but it works for me for now.

mtbdrew · Thu May 16, 2024 5:41 pm

Bit more supplemental information here. Another radar event occurred tonight at 20:27 on 5500 when I happened to be looking. Frequency currently set to 5500, 5580, 5660 and 5180. Caught it doing a 10 min CAC on 5580 so it does work through the frequencies during a radar event. It then stayed on 5580.

I've currently got a schedule task running every hour which restarts the interface so at 21:00 it switched back to 5500. Bit of a fudge but it works for me for now.

Did you ever create a support ticket with Mikrotik regarding this issue? I'm seeing something very similar on my Hap AX2 as well, my Hap AX3 does not have the issue.

robmaltsystems · Fri May 17, 2024 12:37 pm

Not specifically - I have gone a ticket in there about how it processes a list of frequencies but that one was about it not doing a noise check if one specifies a list of frequencies. IMO if you specify freq1, freq2 it should always use freq1 first unless it's a DFS channel and CAC check fails. At the moment, it can often end up on freq2 because it classes freq1 as noisy/busy.

So no, not a specific ticket on the entire 5GHz interface shutting down one frequency supplied and a future radar event occurs. That was because somebody mentioned something in this area in the beta version so I was going to wait.

I've thought and tested this one a lot and IMO it should work like this:

There are three frequency scenarios:

1. Nothing specified at all.
2. Range of frequencies specified.
3. Specific list of frequencies supplied.

In cases 1 & 2, it should do an auto scan by tx power across the entire spectrum (case #1) or the limited spectrum (case #2) checking how noisy/busy each channel is. It should consider tx power and noise together. For example, on a cAP ac in the UK it might be better to use nosier channel 100 over channel 36 because channel 100 is a 30% stronger signal. For each candidate frequency that's DFS, a CAC check needs carrying out.

In case 3, it should not do any kind of noise test but only skip a specified frequency if the CAC radar check fails. It should scan the list in the order specified. If all frequencies specified fail CAC, it should log that and fall back on case #1.

In all cases, if a CAC check failed, a timer should be started to try again in 30 minute. If a radar event occurs in the future, the above processes are followed again and the same timer process is triggered.

Who is online