[PATCH] wiphy: set neighbor report capability flag

[PATCH] wiphy: set neighbor report capability flag

[Michael Johnson]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

As we send a neighbor report request after joining a network we should
be setting the flag in the radio measurement capabilities.

This is required by some Meraki access points.
---
 src/wiphy.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/wiphy.c b/src/wiphy.c
index e2222887..405b17be 100644
--- a/src/wiphy.c
+++ b/src/wiphy.c
@@ -1522,8 +1522,11 @@ static void wiphy_setup_rm_enabled_capabilities(struct wiphy *wiphy)
 
 	wiphy->rm_enabled_capabilities[0] = IE_TYPE_RM_ENABLED_CAPABILITIES;
 	wiphy->rm_enabled_capabilities[1] = 5;
-	/* Bits: Passive (4), Active (5), and Beacon Table (6) capabilities */
-	wiphy->rm_enabled_capabilities[2] = 0x70;
+	/*
+	 * Bits: Neighbor Report (1), Passive (4), Active (5),
+	 * and Beacon Table (6) capabilities
+	 */
+	wiphy->rm_enabled_capabilities[2] = 0x72;
 
 	/*
 	 * TODO: Support at least Link Measurement if TX_POWER_INSERTION is
-- 
2.25.1

Re: [PATCH] wiphy: set neighbor report capability flag

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

Hi Michael,

On 8/3/21 9:19 AM, Michael Johnson wrote:
> As we send a neighbor report request after joining a network we should
> be setting the flag in the radio measurement capabilities.
> 
> This is required by some Meraki access points.

Ugh, I'm not sure Meraki is doing the right thing here...?

802.11-2020:

"A STA sets the Neighbor Report Capability Enabled field to 1 when 
dot11RMNeighborReportActivated is true and sets it to 0 otherwise."

11.10.10.1:
"An AP in which dot11RMNeighborReportActivated is false shall not transmit a 
Fine Timing Measurement Range request. An AP in which 
dot11RMNeighborReportActivated is false should not ..."

11.10.10.3:
"If dot11RMNeighborReportActivated is true, an AP receiving a neighbor report 
request shall respond with a Neighbor Report Response frame containing zero or 
more Neighbor Report elements."

"If dot11RMNeighborReportActivated is false in an AP receiving a neighbor report 
request, it shall ignore the request."

There are no other mentions of this config value in non-AP context.

How does Meraki behave if this capability isn't set?  Likely we can safely set 
this, but I'd want a comment explaining why this was done.

> ---
>   src/wiphy.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 

Regards,
-Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Michael Johnson]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

Hi Denis,

Sorry I realise that I made an erroneous assumption about what
"correct" behavior is in this context.
My current use case for iwd is a linux-based robot that roams heavily.
In most cases we use Meraki access points.

When it comes to roaming, there are multiple issues I am seeing with
support for 802.11k and 802.11v that I expect
are caused by ambiguity in the standard but unfortunately I don't
personally have access to check. This specific issue
is the first time we send a neighbor report, the AP responds with a
correct response. However subsequent requests
either get a blank response or no response at all.

The Meraki support engineer blamed the lack of setting this flag using
these links as supporting evidence
" This mismatch is causing a few artifacts. The awkward or bad
behaviors will be highlighted in bold.

    The client device does not communicate it supports 802.11k
        **The device engages in 802.11k frames despite specified support**
    The Meraki AP does not categorize the client as 802.11k capable as
the client never stated it was capable
        **The Meraki AP still responds to the AP Neighborship Report
with incomplete information**
"
https://mrncciew.com/2014/09/11/cwsp-802-11k-ap-assisted-roaming/
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.html#Assisted_Roaming_with_802.11k

To be completely open, I did some packet captures both with and
without this patch and the Meraki behavior
was equally broken in both cases. In submitting this PR I assumed it
was either part of the standard or at least
a common extension and that it was therefore valuable regardless of
Meraki support. However if that is not the
case then maybe it shouldn't be merged. I was going by online
resources of varying quality that it was
"correct" and I'm no longer convinced it is.

Regards,
Michael

On Tue, 3 Aug 2021 at 16:18, Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Michael,
>
> On 8/3/21 9:19 AM, Michael Johnson wrote:
> > As we send a neighbor report request after joining a network we should
> > be setting the flag in the radio measurement capabilities.
> >
> > This is required by some Meraki access points.
>
> Ugh, I'm not sure Meraki is doing the right thing here...?
>
> 802.11-2020:
>
> "A STA sets the Neighbor Report Capability Enabled field to 1 when
> dot11RMNeighborReportActivated is true and sets it to 0 otherwise."
>
> 11.10.10.1:
> "An AP in which dot11RMNeighborReportActivated is false shall not transmit a
> Fine Timing Measurement Range request. An AP in which
> dot11RMNeighborReportActivated is false should not ..."
>
> 11.10.10.3:
> "If dot11RMNeighborReportActivated is true, an AP receiving a neighbor report
> request shall respond with a Neighbor Report Response frame containing zero or
> more Neighbor Report elements."
>
> "If dot11RMNeighborReportActivated is false in an AP receiving a neighbor report
> request, it shall ignore the request."
>
> There are no other mentions of this config value in non-AP context.
>
> How does Meraki behave if this capability isn't set?  Likely we can safely set
> this, but I'd want a comment explaining why this was done.
>
> > ---
> >   src/wiphy.c | 7 +++++--
> >   1 file changed, 5 insertions(+), 2 deletions(-)
> >
>
> Regards,
> -Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3188 bytes --]

Hi Michael,

On 8/3/21 11:07 AM, Michael Johnson wrote:
> Hi Denis,
> 
> Sorry I realise that I made an erroneous assumption about what
> "correct" behavior is in this context.
> My current use case for iwd is a linux-based robot that roams heavily.
> In most cases we use Meraki access points.
> 

Very cool :)

> When it comes to roaming, there are multiple issues I am seeing with
> support for 802.11k and 802.11v that I expect
> are caused by ambiguity in the standard but unfortunately I don't
> personally have access to check. This specific issue
> is the first time we send a neighbor report, the AP responds with a
> correct response. However subsequent requests
> either get a blank response or no response at all.
> 

Hmm, I wonder if we have a different bug here.  This gives me a few ideas to 
look into, let me poke around and I'll get back to you.

What other problems are you having?

> The Meraki support engineer blamed the lack of setting this flag using
> these links as supporting evidence
> " This mismatch is causing a few artifacts. The awkward or bad
> behaviors will be highlighted in bold.
> 
>      The client device does not communicate it supports 802.11k
>          **The device engages in 802.11k frames despite specified support**
>      The Meraki AP does not categorize the client as 802.11k capable as
> the client never stated it was capable
>          **The Meraki AP still responds to the AP Neighborship Report
> with incomplete information**
> "
> https://mrncciew.com/2014/09/11/cwsp-802-11k-ap-assisted-roaming/

This link shows an Association Request with 'neighbor report' capability zero-d 
out.  See 'Frame 41'

> https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.html#Assisted_Roaming_with_802.11k

This link says:
"The presence of all three of these IEs signifies that this SSID is configured 
to provide a neighbor list on request. For this release we send neighbor list 
based on the request from the client and not on the neighbor list capability of 
the client in the IE. "

I have seen traces where other devices set this bit in the Association Request 
(From memory, so may be incorrect: Apple and a Samsung Android device), but the 
spec is really fuzzy here.  And I don't see how Meraki could interpret the spec 
in a way that makes this a required capability bit on the client.

> 
> To be completely open, I did some packet captures both with and
> without this patch and the Meraki behavior
> was equally broken in both cases. In submitting this PR I assumed it
> was either part of the standard or at least
> a common extension and that it was therefore valuable regardless of
> Meraki support. However if that is not the
> case then maybe it shouldn't be merged. I was going by online
> resources of varying quality that it was
> "correct" and I'm no longer convinced it is.

It could be that Meraki really does want this, but I suspect something else is 
the real culprit.  Lets get to the bottom of this.

> 
> Regards,
> Michael

Regards,
-Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Michael Johnson]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hi Denis,

On Tue, 3 Aug 2021 at 17:35, Denis Kenzior <denkenz@gmail.com> wrote:
> Hmm, I wonder if we have a different bug here.  This gives me a few ideas to
> look into, let me poke around and I'll get back to you.
>
> What other problems are you having?

Thank you!

The other major problem I'm having is when 802.11v is enabled the APs
are not sending BSS-TM frames during re-associations (i.e. FT roams)
but it does work during a full association.
The current suspect is that the client doesn't send the "extended
capabilities" tags in the re-association frame like it does with a
full association. Without this the Meraki APs assume the client
doesn't support it.
I don't know what the standard says about this one.

> > https://mrncciew.com/2014/09/11/cwsp-802-11k-ap-assisted-roaming/
>
> This link shows an Association Request with 'neighbor report' capability zero-d
> out.  See 'Frame 41'

Ah! I completely misread that as enabling an alternative "channel report".

> It could be that Meraki really does want this, but I suspect something else is
> the real culprit.  Lets get to the bottom of this.

Let me know how I can help!

Regards,
Michael

Re: [PATCH] wiphy: set neighbor report capability flag

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Hi Michael,

On 8/3/21 12:41 PM, Michael Johnson wrote:
> Hi Denis,
> 
> On Tue, 3 Aug 2021 at 17:35, Denis Kenzior <denkenz@gmail.com> wrote:
>> Hmm, I wonder if we have a different bug here.  This gives me a few ideas to
>> look into, let me poke around and I'll get back to you.
>>
>> What other problems are you having?
> 
> Thank you!
> 
> The other major problem I'm having is when 802.11v is enabled the APs
> are not sending BSS-TM frames during re-associations (i.e. FT roams)
> but it does work during a full association.
> The current suspect is that the client doesn't send the "extended
> capabilities" tags in the re-association frame like it does with a
> full association. Without this the Meraki APs assume the client
> doesn't support it.
> I don't know what the standard says about this one.
> 

I believe I have fixed this upstream now with commit 8f9e6b3f7626 ("netdev: Send 
addititional IEs for FT/SAE/OWE/FILS")

Can you give it another try?

Regards,
-Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Michael Johnson]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Hi Denis,

Thanks for the quick fix. I've confirmed the fields are being set on
my client but I won't be able to check the behavior until next week as
it requires some changes to my test environment. I'll let you know how
it goes.

I've also asked Meraki to clarify on the Neighbor Report field and
will let you know when I hear back.

Thanks again,
Michael

On Fri, 6 Aug 2021 at 03:10, Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Michael,
>
> On 8/3/21 12:41 PM, Michael Johnson wrote:
> > Hi Denis,
> >
> > On Tue, 3 Aug 2021 at 17:35, Denis Kenzior <denkenz@gmail.com> wrote:
> >> Hmm, I wonder if we have a different bug here.  This gives me a few ideas to
> >> look into, let me poke around and I'll get back to you.
> >>
> >> What other problems are you having?
> >
> > Thank you!
> >
> > The other major problem I'm having is when 802.11v is enabled the APs
> > are not sending BSS-TM frames during re-associations (i.e. FT roams)
> > but it does work during a full association.
> > The current suspect is that the client doesn't send the "extended
> > capabilities" tags in the re-association frame like it does with a
> > full association. Without this the Meraki APs assume the client
> > doesn't support it.
> > I don't know what the standard says about this one.
> >
>
> I believe I have fixed this upstream now with commit 8f9e6b3f7626 ("netdev: Send
> addititional IEs for FT/SAE/OWE/FILS")
>
> Can you give it another try?
>
> Regards,
> -Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Michael Johnson]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

Hi Denis,

A couple of updates today after some testing.

Firstly the fix done to add the extended capabilities tags in FT roams
worked and I had successful 802.11v behaviour with Meraki access
points. Thank you very much for that.

Secondly, Meraki have checked their behavior and are now agreeing that
the Neighbor Report field does not need to be set for .11k to work
correctly and that they have a bug relating to the optional SSID tag
not being included in the message. However they are still saying that
setting the Neighbor Report field is subjectively "correct" citing
section 6.3.30 of the 2020 edition of the standard (being completely
open it is an interpretation rather than solid requirement).
Personally, I think it makes sense for it to be set when it is
supported but I don't suppose it makes much difference either way.

Kind Regards,
Michael

On Fri, 6 Aug 2021 at 16:28, Michael Johnson <mjohnson459@gmail.com> wrote:
>
> Hi Denis,
>
> Thanks for the quick fix. I've confirmed the fields are being set on
> my client but I won't be able to check the behavior until next week as
> it requires some changes to my test environment. I'll let you know how
> it goes.
>
> I've also asked Meraki to clarify on the Neighbor Report field and
> will let you know when I hear back.
>
> Thanks again,
> Michael
>
> On Fri, 6 Aug 2021 at 03:10, Denis Kenzior <denkenz@gmail.com> wrote:
> >
> > Hi Michael,
> >
> > On 8/3/21 12:41 PM, Michael Johnson wrote:
> > > Hi Denis,
> > >
> > > On Tue, 3 Aug 2021 at 17:35, Denis Kenzior <denkenz@gmail.com> wrote:
> > >> Hmm, I wonder if we have a different bug here.  This gives me a few ideas to
> > >> look into, let me poke around and I'll get back to you.
> > >>
> > >> What other problems are you having?
> > >
> > > Thank you!
> > >
> > > The other major problem I'm having is when 802.11v is enabled the APs
> > > are not sending BSS-TM frames during re-associations (i.e. FT roams)
> > > but it does work during a full association.
> > > The current suspect is that the client doesn't send the "extended
> > > capabilities" tags in the re-association frame like it does with a
> > > full association. Without this the Meraki APs assume the client
> > > doesn't support it.
> > > I don't know what the standard says about this one.
> > >
> >
> > I believe I have fixed this upstream now with commit 8f9e6b3f7626 ("netdev: Send
> > addititional IEs for FT/SAE/OWE/FILS")
> >
> > Can you give it another try?
> >
> > Regards,
> > -Denis

Re: [PATCH] wiphy: set neighbor report capability flag

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Hi Michael,

On 8/18/21 12:39 PM, Michael Johnson wrote:
> Hi Denis,
> 
> A couple of updates today after some testing.
> 
> Firstly the fix done to add the extended capabilities tags in FT roams
> worked and I had successful 802.11v behaviour with Meraki access
> points. Thank you very much for that.

Awesome, thanks for testing!

> 
> Secondly, Meraki have checked their behavior and are now agreeing that
> the Neighbor Report field does not need to be set for .11k to work
> correctly and that they have a bug relating to the optional SSID tag
> not being included in the message. However they are still saying that
> setting the Neighbor Report field is subjectively "correct" citing
> section 6.3.30 of the 2020 edition of the standard (being completely

Did they quote the exact parts they're interpreting by any chance?  I quickly 
went over this section, but nothing jumps out at me.

> open it is an interpretation rather than solid requirement).
> Personally, I think it makes sense for it to be set when it is
> supported but I don't suppose it makes much difference either way.

Ok.  Let me stare at this section some more.  Generally I agree that there is 
probably no harm in setting this bit as the STA.  But, it would be nice to have 
a quote from 802.11-2020 (even if it is open to interpretation) that could be 
used in the commit message as the justification.

Regards,
-Denis