802.11k (Assisted Roaming) on NWA210AX (and likely other models)

Options
bapplegate513
bapplegate513 Posts: 4
edited August 2022 in WirelessLAN
Hello,

I just got my second NWA210AX.  I have two of these configured identically with regard to SSID/security etc.  My devices jump from one to the other as expected (different floors of my house).  I have 802.11k/v enabled on all SSIDs on both APs.  Running newest available firmware (6.25). They are both running standalone (No Nebula).

Once I got all this set up and rebooted both devices, I see a couple of things (expected and good):

  • 802.11 Features column in Station List in GUI shows devices supporting 802.11k/v (in my case, lots of iPhone and Raspberry PI).
  • Running a wifi sniffer (monitor mode) and inspecting the beacons shows that my APs are advertising RRM (radio resource management) capabilities (specifically neighbor report).
  • CLI shows 802.11k candidate neighbor reports (detailed below).  Both AP's list the  other as a roaming candidate.

Here are the (snipped/sanitized) outputs from: "show dot11k neighbor report all"


AP1:


index: 1
  MAC: b8:27:eb:xx:xx:xx
    BSSID: <AP2's BSSID>
    Channel: 42

AP2:

index: 2
  MAC: 50:14:79:xx:xx:xx
    BSSID: <AP1's BSSID>
    Channel: 100

So if I'm understanding that command output correctly (there is essentially 0 details/documentation on that command), this means that each respective AP would reply with the other AP's BSSID and Channel in a Neighbor Report.

So far so good, but this is where the good news ends.

I have a sniffer running on one of the channels of one of the AP's.  I have tried both Raspberry Pis to manually "roam" (using wpa_cli command), as well as walking to the basement with a cheap Android tablet.  In both cases I can see the Neighbor Report Request - but I never see the actual neighbor report come from an AP.  Ironically, I'm able to pick up some neighbors (down the street/humans) Netgear AP sending these reports to their clients.  My Zyxels seem like they stop at this point and don't actually respond.

Anyone else jumped through these hoops and can confirm this behavior ?  802.11k/v looks to be just a check box - not really anything else I can see to do to make this work.

If you made it this far reading - I appreciate it.  Thanks.

Best Answers

  • Zyxel_Bella
    Zyxel_Bella Posts: 437  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Answer ✓
    Options

    Hi @bapplegate513

     

    Our AP’s current implementation is to use 11k to collect beacon reports and organize them into a neighbor list when the condition matches following two situations.

     

    a. When the station initiative sends a neighbor request, AP will send the suggested roaming target AP (neighbor list) to the station, but not all the station may send a neighbor request when it wants to roaming to get the suggested roaming target AP and AP does not send the suggested roaming target AP for the station to make appropriate roaming choices.

     

    b. When band select and assisted roaming enable, AP will send the suggested roaming target AP (neighbor list) to the station according to band loading. It is recommended that station roaming from 2.4GHz to 5GHz. This refers to band steering feature.

     

    In order to clarify if the AP works as expected behavior, we setup a lab and result as below. There are two APs broadcast same SSIDs and station connected to 192.168.1.34 first, keep running command “show dot11k neighbor report all” on another AP 192.168.1.33 to check the neighbor list. Then bring the hand device to work far away from connected AP, the target AP shows the station information after signal drops below -70dBm. 


    At final, the station connected to the target AP.

     

     

    Not sure if your Raspberry Pi is the device that may send a neighbor request or not in this case. We could have a look into both your AP’s diagnostics file, could you collect right after your test was done?

     

    Thanks for your help.

     

    Regards,

    Bella

     


  • bapplegate513
    bapplegate513 Posts: 4
    Answer ✓
    Options
    Well I think I figured this out.  This is going to be a bit long - but the TL;DR is that I have MFP (management frame protection) set as optional (a function of WPA3 / WPA2 backward compat. I think).  I think this *is* working, and the neighbor report is encrypted (as in MFP is working and doing it's job).

    Here is the tcpdump filter I used to capture 802.11k frames (codes 4 + 5).  I did this on Linux on monitor mode (so radiotap headers). I say that because I'm doing this the "hard way" and looking at specific byte offsets.  If you capture a different way this filter might not work as-is:

    'ether[25] == 0x04 or ether[25] == 0x05' and 'ether[0] == 0xd0'
    Here is something I randomly captured from another (Netgear) AP.  This AP doesn't have MFP enabled it seems, and the neighbor reports are readable/decodeable:



    Here's what I see on my Zyxels.  The first is my neighbor report request, the second is (probably) the response (it comes immediately after, these are frames 2 + 3 in my capture)  Note the "CCMP Parameters" there that the Netgear frame doesn't have.  That's why the end of the frame is "Data" in Wireshark - it's encrypted:





    Thanks for your time Bella, sorry this was a bit of a goose chase.  If nothing else - I certainly learned a lot.

All Replies

  • Zyxel_Bella
    Zyxel_Bella Posts: 437  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Hi @bapplegate513

     

    Welcome to Zyxel community.

    First, we’d like to your firmware patch version of the NWA210AX is running.

    Since there is a known issue related to roaming of WiFi 6 APs in the first release V6.25 firmware and we suggest to upgrade to latest patch V6.25(ABTD.2)C0.

    https://www.zyxel.com/nl/nl/support/download_library/product/nwa210ax_14.shtml?c=nl&l=nl&pid=20190717120008&tab=Firmware&pname=NWA210AX&mtname=Firmware

    If the problem still exists after applied the latest patch, feel free to update us and we’ll help you to check.

    Thank you

     

    Regards,

    Bella

     


  • bapplegate513
    bapplegate513 Posts: 4
    edited November 2021
    Options
    Thanks for the reply.  Sorry I should have been more clear - I'm already running that (C0) version:

    V6.25(ABTD.2)C0

    Hopefully if this is a known issue more work will be done for future firmware releases.

    Let me know if you need any more information.
  • Zyxel_Bella
    Zyxel_Bella Posts: 437  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Hi @bapplegate513

     

    Thanks for the information.

    From your description, can we say that the symptom happens after firmware upgrade to V6.25 patch 2 and AP not sending the report is not always but sometimes?

    We also want to ask about the previous firmware version that works fine as you state.

    Many thanks!

     

    Regards,

    Bella

     

     


  • bapplegate513
    bapplegate513 Posts: 4
    Options
    Hello,

    Actually this is the first time I've used Zyxel hardware.  As soon as I got these units I upgraded to the latest firmware ( V6.25(ABTD.2)C0 ).  So I've never ran any older firmware.

    As far as I can tell, my AP's never send a neighbor report.  I see the neighbor request come from some of my clients, and immediately after I see *something* from the AP, but Wireshark can't decode it and it shows up as "data".  Wireshark can decode neighbor reports from other (non-Zyxel) APs.
  • Zyxel_Bella
    Zyxel_Bella Posts: 437  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Answer ✓
    Options

    Hi @bapplegate513

     

    Our AP’s current implementation is to use 11k to collect beacon reports and organize them into a neighbor list when the condition matches following two situations.

     

    a. When the station initiative sends a neighbor request, AP will send the suggested roaming target AP (neighbor list) to the station, but not all the station may send a neighbor request when it wants to roaming to get the suggested roaming target AP and AP does not send the suggested roaming target AP for the station to make appropriate roaming choices.

     

    b. When band select and assisted roaming enable, AP will send the suggested roaming target AP (neighbor list) to the station according to band loading. It is recommended that station roaming from 2.4GHz to 5GHz. This refers to band steering feature.

     

    In order to clarify if the AP works as expected behavior, we setup a lab and result as below. There are two APs broadcast same SSIDs and station connected to 192.168.1.34 first, keep running command “show dot11k neighbor report all” on another AP 192.168.1.33 to check the neighbor list. Then bring the hand device to work far away from connected AP, the target AP shows the station information after signal drops below -70dBm. 


    At final, the station connected to the target AP.

     

     

    Not sure if your Raspberry Pi is the device that may send a neighbor request or not in this case. We could have a look into both your AP’s diagnostics file, could you collect right after your test was done?

     

    Thanks for your help.

     

    Regards,

    Bella

     


  • bapplegate513
    bapplegate513 Posts: 4
    Answer ✓
    Options
    Well I think I figured this out.  This is going to be a bit long - but the TL;DR is that I have MFP (management frame protection) set as optional (a function of WPA3 / WPA2 backward compat. I think).  I think this *is* working, and the neighbor report is encrypted (as in MFP is working and doing it's job).

    Here is the tcpdump filter I used to capture 802.11k frames (codes 4 + 5).  I did this on Linux on monitor mode (so radiotap headers). I say that because I'm doing this the "hard way" and looking at specific byte offsets.  If you capture a different way this filter might not work as-is:

    'ether[25] == 0x04 or ether[25] == 0x05' and 'ether[0] == 0xd0'
    Here is something I randomly captured from another (Netgear) AP.  This AP doesn't have MFP enabled it seems, and the neighbor reports are readable/decodeable:



    Here's what I see on my Zyxels.  The first is my neighbor report request, the second is (probably) the response (it comes immediately after, these are frames 2 + 3 in my capture)  Note the "CCMP Parameters" there that the Netgear frame doesn't have.  That's why the end of the frame is "Data" in Wireshark - it's encrypted:





    Thanks for your time Bella, sorry this was a bit of a goose chase.  If nothing else - I certainly learned a lot.

Categories

WLAN Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）