12:19 a.m.
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
1:02 a.m.
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
2:07 a.m.
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-...
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(a)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
2:19 a.m.
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'
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
3:41 a.m.
Hi Denis,
On Tue, 3 Aug 2021 at 17:35, Denis Kenzior <denkenz(a)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
12:10 p.m.
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(a)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
1:28 a.m.
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(a)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(a)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
3:39 a.m.
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(a)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(a)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(a)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
4:11 a.m.
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
396
days inactive
411
days old
8 comments
2 participants
participants (2)
-
Denis Kenzior -
Michael Johnson