hAP ax²: clients connection stability issue

sbert · Mon Apr 22, 2024 1:49 pm

Hi.

I am trying to substitute the actual hAP ac with a new hAP ax² for my home network, but I am facing stability with the connectivity of devices (for example my Samsung Smart TV).

When the hAP ax² is restarted, all clients connect, but after a while, one or more disconnects (and do not connect anymore).

I also tried to upgrade to the latest 7.15rc1 which has a driver upgrade for wifi-qcom.

Any suggestion? Is someone else experiencing stability with client connectivity stability?

Stefano

dwnldr · Tue Apr 23, 2024 4:16 pm

Hi !

What kind of settings do you have ? Are you using Fast Transition (some devices still cannot live/survive this) and WPA3 (same...) ?
For testing purposes try to config your device without FT and secure with WPA2 CCMP only. Also prlomging dhcp lease time and group key update can solve such issues, which are luckily for me with wave2 finally unknown...

sbert · Wed Apr 24, 2024 5:45 pm

hAP ax² configured as single AP: no capMAN, no other APs for roaming.

Here is the configuration:

[admin@MikroTik] > interface/wifi/print detail
Flags: M - master; D - dynamic; B - bound; X - disabled, I - inactive, R - running 
 0   BR name="WiFi_2-Devices" l2mtu=1560 mac-address=4A:A9:8A:69:D2:AF arp-timeout=auto master-interface=WiFi_2-Main 
        configuration.mode=ap .ssid="WiFi-2 - Devices" 
        security.authentication-types=wpa2-psk .passphrase="xxxyyyzzz" 
        datapath.bridge=Bridge-Device .client-isolation=yes 

 1   BR name="WiFi_2-IoT" l2mtu=1560 mac-address=4A:A9:8A:69:D2:AE arp-timeout=auto master-interface=WiFi_2-Main 
        configuration.mode=ap .ssid="WiFi-2 - IoT" 
        security.authentication-types=wpa2-psk .passphrase="xxxyyyzzz" 
        datapath.client-isolation=yes 

 2 M B  default-name="wifi2" name="WiFi_2-Main" l2mtu=1560 mac-address=48:A9:8A:69:D2:AE arp-timeout=auto radio-mac=48:A9:8A:69:D2:AE 
        configuration=PippoNet-conf 
        configuration.mode=ap .ssid="WiFi-2" .country=Italy 
        security.authentication-types=wpa2-psk,wpa3-psk .passphrase="xxxyyyzzz" 
        datapath.bridge=Bridge-LAN 
        channel=ch-2ghz 
        channel.frequency=2412,2437 .width=20mhz 

 3 M BR default-name="wifi1" name="WiFi_5-Main" l2mtu=1560 mac-address=48:A9:8A:69:D2:AD arp-timeout=auto radio-mac=48:A9:8A:69:D2:AD 
        configuration=PippoNet-conf 
        configuration.mode=ap .ssid="WiFi-5" .country=Italy 
        security.authentication-types=wpa2-psk,wpa3-psk .passphrase="xxxyyyzzz" 
        datapath.bridge=Bridge-LAN 
        channel=ch-5ghz 
        channel.frequency=5180 .width=20/40/80mhz

Randomly the clients get disconnected, without any clear reason:

16:27:37 echo: wireless,info 78:BD:BC:DD:00:31@WiFi_2-IoT disconnected, connection lost, signal strength -76
16:27:37 echo: wireless,debug 78:BD:BC:DD:00:31@WiFi_2-IoT disassociated, connection lost, signal strength -76
16:28:35 echo: wireless,debug 78:BD:BC:DD:00:31@WiFi_2-IoT associated, signal strength -75
16:28:35 echo: wireless,info 78:BD:BC:DD:00:31@WiFi_2-IoT connected, signal strength -75
16:30:19 echo: wireless,info 78:BD:BC:DD:00:31@WiFi_2-IoT disconnected, connection lost, signal strength -76
16:30:19 echo: wireless,debug 78:BD:BC:DD:00:31@WiFi_2-IoT disassociated, connection lost, signal strength -76

As mentioned, it is happening with hAP ax², but not with hAP ac lite.

Is there any configuration for the threshold for the signal strength to disconnect a client?

infabo · Wed Apr 24, 2024 5:56 pm

Please issue an export and paste here. thanks

/interface/wifi/export

sbert · Wed Apr 24, 2024 6:21 pm

# 2024-04-24 17:29:26 by RouterOS 7.15rc1
# software id = IQJT-ARXV
#
# model = C52iG-5HaxD2HaxD
# serial number = HE608P3JDNE
/interface wifi channel
add disabled=no frequency=2412 name=ch-2ghz width=20mhz
add disabled=no frequency=5180 name=ch-5ghz width=20/40/80mhz
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no name=Main-auth
/interface wifi
add configuration.mode=ap .ssid="PippoNet - Devices" datapath.bridge=Bridge-Device .client-isolation=yes disabled=no mac-address=\
    4A:A9:8A:69:D2:AF master-interface=WiFi_2-Main name=WiFi_2-Devices security.authentication-types=wpa2-psk
add configuration.mode=ap .ssid="PippoNet - IoT" datapath.client-isolation=yes disabled=no mac-address=4A:A9:8A:69:D2:AE \
    master-interface=WiFi_2-Main name=WiFi_2-IoT security.authentication-types=wpa2-psk
set [ find default-name=wifi2 ] channel=ch-2ghz channel.frequency=2412,2437 configuration=PippoNet-conf configuration.mode=ap \
    datapath.bridge=Bridge-LAN disabled=no name=WiFi_2-Main
set [ find default-name=wifi1 ] channel=ch-5ghz configuration=PippoNet-conf configuration.country=Italy .mode=ap datapath.bridge=\
    Bridge-LAN disabled=no name=WiFi_5-Main
/interface wifi configuration
add country=Italy datapath.bridge=Bridge-LAN disabled=no name=PippoNet-conf security=Main-auth ssid=PippoNet

infabo · Wed Apr 24, 2024 11:01 pm

Your configuration looks legit.

But there are some lines that confuse me:

/interface wifi
add configuration.mode=ap .ssid="PippoNet - Devices" datapath.bridge=Bridge-Device .client-isolation=yes disabled=no mac-address=\
    4A:A9:8A:69:D2:AF master-interface=WiFi_2-Main name=WiFi_2-Devices security.authentication-types=wpa2-psk

It should be "configuration.ssid" and "datapath.client-isolation=yes" instead.

Next line again:

add configuration.mode=ap .ssid="PippoNet - IoT" datapath.client-isolation=yes disabled=no mac-address=4A:A9:8A:69:D2:AE \
    master-interface=WiFi_2-Main name=WiFi_2-IoT security.authentication-types=wpa2-psk

It should be "configuration.ssid" and not just ".ssid".

And here another:

set [ find default-name=wifi1 ] channel=ch-5ghz configuration=PippoNet-conf configuration.country=Italy .mode=ap datapath.bridge=\
    Bridge-LAN disabled=no name=WiFi_5-Main

"configuration.mode=ap" instead of ".mode=ap".

I don't know where this originates from, but maybe this is the quirk here.

Thu Apr 25, 2024 1:02 am

It should be "configuration.ssid" and "datapath.client-isolation=yes" instead.

The abbreviation is standard, emitted by RouterOS, not something the user did. You can see an example of it here, in MT's own docs.

infabo · Thu Apr 25, 2024 1:54 am

tangent, you linked to a sample of "actual-configuration print". The OP posted an export.

Lets try together:

/interface/wifi/set .ssid="foobar"

What does it say? "expected end of command"

/interface/wifi/set configuration.mode=ap .ssid="foobar"

Works. ROS is a magic

jaclaz · Thu Apr 25, 2024 1:07 pm

It seems it is a parent/child convention, using the dot as separator.

With
set configuration.mode=ap
you are setting at the same time parent (configuration) and child (mode)
with
.ssid="foobar"
you are setting just the child (ssid) and the last used parent is implied.

It seems to me like useful for avoiding typing (like Ros command shortenings) but it is a bit confusing in an export.

infabo · Thu Apr 25, 2024 1:48 pm

Yeah, I understand the logic behind it. It's some kind of "chaining". But still it is confusing to see this in an export.

Nullcaller · Fri Apr 26, 2024 4:27 am

ROS7 syntax, now with 20% more sugar!

mkx · Fri Apr 26, 2024 8:25 am

It's called compression ... basic idea behind all compression algorithms is to remove any redundant information from data set ... even if that information doesn't seem redundant to humans' minds.

infabo · Fri Apr 26, 2024 9:41 am

hah! now the tools are available to save some space on 16MB flash devices.

sbert · Fri Apr 26, 2024 10:23 am

Resuming: the wi-fi configuration looks fine and there are no evident errors.

I still don't have any ideas where to look at and fix the device connection stability issue.

For example: when watching Netflix on SmartTV, often the streaming stops; to fix it, I block and unblock the wifi interface (via Winbox) to force the device to re-connect. It works for a while.

When it doesn't work anymore, power reset: even the SW reboot sometimes doesn't fix the problem.

How can I proceed? Opening a ticket?

ips · Fri Apr 26, 2024 3:48 pm

I cannot get where WiFi_2-Main's security is configured. Am I missing something?

erlinden · Fri Apr 26, 2024 3:57 pm

Try enabling wifi logging and check the log.
For me it worked best when having only WPA2 AES.

ips · Fri Apr 26, 2024 4:06 pm

Post viewtopic.php?p=1071902#p1071489 already reports an extract of the debugging log, doesn't it?

erlinden · Fri Apr 26, 2024 4:33 pm

Post viewtopic.php?p=1071902#p1071489 already reports an extract of the debugging log, doesn't it?

You are (obviously) absolutely right. Was expecting other kind of log entries.

Did you also give my other remark a try?

ips · Fri Apr 26, 2024 7:22 pm

Actually my TV does not have issues and, indeed, I am not the OP.

sbert · Sat Apr 27, 2024 9:41 pm

I enabled the wireless logs and I see the wifi clients actively exchanging traffic having the same issue.

For example, my laptop is disconnecting with the reason "SA Query timeout" (?!?):

wireless,debug B0:3C:DC:E1:66:67@WiFi_2-Main reauthenticating
wireless,info B0:3C:DC:E1:66:67@WiFi_2-Main disconnected, SA Query timeout, signal strength -67
wireless,debug B0:3C:DC:E1:66:67@WiFi_2-Main disassociated, SA Query timeout, signal strength -67
wireless,debug B0:3C:DC:E1:66:67@WiFi_2-Main associated, signal strength -66
wireless,info B0:3C:DC:E1:66:67@WiFi_2-Main connected, signal strength -65
wireless,debug 00:BB:3A:E7:7E:8A@WiFi_2-Devices associated, signal strength -64

The difference is that most of the other wifi clients can reconnect (and reconnect again) without any problem.

Instead, with my Sambung Smart TV (an "old" model with WiFi 4), after a while watching Netflix, gets stuck and I need to restart the modem. In the past, with hAP ax², the iRobot didn't connect (with new SW versions the problem is not present anymore).

Did you try to enable wireless' logs on your side to verify the behavior? But the WiFI clients should actively be exchanging traffic.

robmaltsystems · Tue Apr 30, 2024 7:16 pm

hAP ax2 user at home here in my office/lab. Also experiencing SA Query timeouts with my laptop. Never had a problem before when I used the Virgin Media Superhub. There is another post on this. My Lenovo laptop has a Realtek 8822CE 802.11ac Wi-Fi chip on the motherboard. I'm currently using a USB Realtek 8832CR WiFi 6 USB adapter and that's fine.

Different frequencies on different devices have different strengths - this certainly crossed over SA Query timeout problems. I've logged a few in the UK. Specifically 5180 which is the only workable non-DFS channel typically has the lowest signal strength in the UK. Not that I'm using USA as the country in the UK. Never find me doing that. There are also posts that the tables in RouterOS for the signal strength limits per frequency are wrong for some countries.

I therefore set my frequency to 5500 as best signal strength and only 1 minute CAC for radar check. Except... I sometimes got a fake radar event which as far as I can tell, disabled 5G. I'd come back into the office the next day and no 5G at all. Had to restart the interface.

IMO this is a flaw - if a single frequency is specified and it can't be used due to radar event, it should resort to auto mode and pick at least a working frequency. It should also retry the original frequency 30 minutes later as per the DFS standard and switch back to it. Especially as my radar events do appear to be fake events. It NEVER gets them during the initial check. It IMO does neither of these.

I've therefore got it configured like this:

And I've got this scheduled script running every hour to switch back to 5500:

# Restart private-5g wi-fi interface if not on channel 5500.
:local interface [/interface/wifi/monitor private-5g as-value once]; 
:local currentchannel ($interface->"channel");
:if ($currentchannel != "5500/ax/Ceee") do={
	:log warning "Wi-Fi channel is $currentchannel, restarting interface"
	/interface/wifi/disable private-5g
	/interface/wifi/enable private-5g 
} else={
	:put "Nothing to do, channel is 5500"
}

There have been OS updates since I got the above working but as it gave me a stable setup, I've not tried going back. Doesn't help with SA Query timeouts though. I've "fixed" that for now by the aforementioned Wi-F6 6 USB adapter.

robmaltsystems · Tue Apr 30, 2024 7:25 pm

has anyone tried to set "disabled" for management protection?

This was the other suggestion made that I've not tried yet.

infabo · Tue Apr 30, 2024 7:28 pm

IMO this is a flaw - if a single frequency is specified and it can't be used due to radar event, it should resort to auto mode and pick at least a working frequency

No, that would be a flaw. You certainly have a reason to restrict the frequency to a single one. If you want a "fallback", you need to configure at least a second frequency.

It should also retry the original frequency 30 minutes later as per the DFS standard and switch back to it.

This is the real issue. ROS simply does not re-check the channel. And that's why it stays down forever. It should do a 1min CAC check after a 30min silence and get the damn interface up und running again.

robmaltsystems · Tue Apr 30, 2024 7:47 pm

No, that would be a flaw. You certainly have a reason to restrict the frequency to a single one. If you want a "fallback", you need to configure at least a second frequency.

I might agree with this but as you say, the flaw is that it never tries CAC again after 30 minutes. If you had 5500, 5180 programmed in there and a radar event occurs on 5500, sure fail back to 5180 but then go back to 5500 after 30 mins if the CAC passes.

I've also been told that RouterOS also carries out some non-CAC checks on each frequency so even if you specify 5500, 5180 you can often find it's chosen 5180 without even doing a CAC check. I regularly see this at a very busy (Wi-Fi interference wise) bar. If I program in the best order for cAP ac in UK (5500, 5660, 5580, 5260, 5180), I often see all four access points huddled on 5180. If I remove from CAPs to force them to reconfigure, they often jump straight to 5180 without doing any CAC checks. Weirdly, when I look at the 5GHz channel usage in InSSIDer, the 5GHz channels don't look that busy so why it's going back to 5180 is a bit of a mystery. When I program (say) just 5500, that channel is always used but I guess because if there is a single frequency, there's no reason in doing any kind of checks (except CAC).

Considering one of the strengths of RouterOS is the power of configuration, not been able to disable additional frequency checks when a manual list has been supplied seems an ommission.

Noise check maybe? This also doesn't feel right. If I've put in specific frequencies in order, I expect them to be used if and only work down the list if, and only if, the initial CAC check fails. Sure, do noise and "busy" checks if no frequency is set and therefore I'm asking RouterOS to find the strongest and least congested channel.

This all feels a bit off to me.

ToTheFull · Tue Apr 30, 2024 8:07 pm

Quick question , If I am using capsman as a controller on ax gear, is the controller responsable for checking for radar. Or does the AP that is controlled by capsman do the check. The reason I am asking is since using capsman I don't get any radar problems on 5500, and the device that runs capsman is hidden in the bowls of my living room behind many walls.

mkx · Tue Apr 30, 2024 8:54 pm

Or does the AP that is controlled by capsman do the check.

Radar checks are always done by device which does Tx/Rx ... which means AP.

ToTheFull · Tue Apr 30, 2024 11:26 pm

Or does the AP that is controlled by capsman do the check.

Radar checks are always done by device which does Tx/Rx ... which means AP.

Ok thanks. Must have been pure coincidence then.

robmaltsystems · Wed May 01, 2024 10:45 am

Maybe not coincidence because whilst the access point carries out the physical radar check, it could be CAPsMAN that decides what to do with the radar event and which frequency to move to?

My reasoning here is that CAPsMAN holds the configuration data on frequency, not the access point?

When I talk about radar events, I mean events that occur long after the access point first starts up, not the initial CAC check. They show up in the logs. In nearly all my tests, I've never seen the CAC check fail at initial start-up. In fact, in a very interference heavy site running cAP ac, I've never seen a radar event and that's a CAPsMAN controlled setup. I've only ever seen it at home on my standalone hAP ax2 where there are surrounding neighbour access points but I really do doubt "real" radar.

So it's entirely possible that the code run through when a radar event occurs is different between a standalone and CAPsMAN controlled device. If the code path is different, a different outcome is entirely possible.

ToTheFull · Wed May 01, 2024 11:25 am

Maybe not because whilst the access point carries out the physical radar check, it could be CAPsMAN that decides what to do with event and which frequency to move to?

My reasoning here is that CAPsMAN holds the configuration data on frequency, not the access point?

When I talk about radar events, I mean events that occur long after the access point first starts up, not the initial CAC check.

Yes this!

Santi70 · Wed May 01, 2024 11:36 am

Maybe not coincidence because whilst the access point carries out the physical radar check, it could be CAPsMAN that decides what to do with the radar event and which frequency to move to?

My reasoning here is that CAPsMAN holds the configuration data on frequency, not the access point?

When I talk about radar events, I mean events that occur long after the access point first starts up, not the initial CAC check. They show up in the logs. In nearly all my tests, I've never seen the CAC check fail at initial start-up. In fact, in a very interference heavy site running cAP ac, I've never seen a radar event and that's a CAPsMAN controlled setup. I've only ever seen it at home on my standalone hAP ax2 where there are surrounding neighbour access points but I really do doubt "real" radar.

So it's entirely possible that the code run through when a radar event occurs is different between a standalone and CAPsMAN controlled device. If the code path is different, a different outcome is entirely possible.

I have an ax3 with capsman along with an ax2 AP and from time to time I get a radar event

infabo · Wed May 01, 2024 12:03 pm

@robmaltsystems there are some changes in upcoming ROS 7.15 which maybe address some of your issues.

*) wifi - added "reselect-interval" support;
*) wifi - improve channel selection after radar detection events;
*) wifi - improved stability of DFS check in the 5GHz-A band;

"improve" and "improve stability" is MikroTik jargon.

- "improve": we fixed one specific bug on mentioned topic.
- "improve stability": we fixed a crash of system/service/command/device triggered by specific actions/conditions

robmaltsystems · Wed May 01, 2024 12:06 pm

That's good news - looks like they're aware of the issues. This post has wandered a little from the original poster with general connection stability issues into SA Query Timeout, into signal strength and into radar check issues. They're all probably wrapped up together!

mkx · Wed May 01, 2024 12:21 pm

Maybe not coincidence because whilst the access point carries out the physical radar check, it could be CAPsMAN that decides what to do with the radar event and which frequency to move to?

My reasoning here is that CAPsMAN holds the configuration data on frequency, not the access point?

CAPsMAN indeed does provisioning ... but it could send the whole frequency list to CAP. This part is something only MT knows.

One thing is certain: radar detection (and acting upon positive result) and subsequent channel scanning is definitely done by CAP. The former is very time critical, AP is required to stop transmitting immediately (connection between CAP and CAPsMAN can be routed and in this case RTT of tens if not hundreds of milliseconds is to be expected). The later (and also the former) is bandwidth demanding and WiFi chip incorporates a DSP chip to do the processing.
In either case CAP does communicate results with CAPsMAN, the only unknown is who makes decission.

robmaltsystems · Wed May 01, 2024 1:26 pm

This part is something only MT knows.

Indeed and that's why I'd love for the engineers to engage in some of these "chewing the fat" discussions. Sure, I know they're busy, busy, busy but I feel it would help overall. Not in here though, too much noise

So a separate discussion system. Happens a lot in Open Source development.

sbert · Thu May 02, 2024 12:22 pm

@robmaltsystems there are some changes in upcoming ROS 7.15 which maybe address some of your issues.
Code: Select all
*) wifi - added "reselect-interval" support;
*) wifi - improve channel selection after radar detection events;
*) wifi - improved stability of DFS check in the 5GHz-A band;
"improve" and "improve stability" is MikroTik jargon.

- "improve": we fixed one specific bug on mentioned topic.
- "improve stability": we fixed a crash of system/service/command/device triggered by specific actions/conditions

Before opening the discussion, I installed the new 7.15rc2 to verify if the changes included fixed something; no notable improvements.

infabo · Thu May 02, 2024 11:05 pm

sbert, did you report/experience any of the highlighted issues from the changelog I posted? you talked about clients losing connection or not even connecting at all. so yes, you can't expect your issues fixed as there's no hint in changelog at all.

sbert · Tue May 07, 2024 9:58 pm

The issue looks fixed disabling management-protection in Security Profile. With this configuration,WPA3 cannot be used.

hAP ax²: clients connection stability issue

hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Re: hAP ax²: clients connection stability issue

Who is online