Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

[Dariusz Gadomski]

Hi,

There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware [1].
I am unaware how that works exactly behind the scenes (except for some hints at
[2]), but I have noticed that with that setting set to “Deny” I am observing
issues when trying to connect from a machine with an Intel 8260 on a 4.10.0
kernel - all connection attempts lead to failure.

I have managed to obtain some captured packets from that attempt as well as
from a successful attempt (a machine with Broadcom bcm43224). What I have
noticed is that AP puts the P2P IE in the beacon frames and when 8260 sends a
probe request it also puts a P2P IE element in it. No response from the AP is
ever transmitted.

In case of the Broadcom-based device the probe request does not contain P2P IE
and it is able to correct normally. My understanding of this issue is that the
AP makes the decision to temporarily blacklist the client after receiving a P2P
IE from it.

I have made an additional test by commenting out the P2P interface types from
iwlwifi/mvn/mac80211.c - using such kernel allowed the 8260 device to connect
successfully.

I’m wondering if there’s a way of changing this behavior to enable the 8260 to
connect to a network ‘secured’ in this way?  I would also appreciate some
information about which behavior is correct (bcm43224 vs 8260) and is it
specified anywhere in the Wi-Fi P2P specs (or anywhere else ftm)?

Thanks, Dariusz

[1] https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_010111110.html
[2] https://supportforums.cisco.com/discussion/11851216/wi-fi-direct-client-policy

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

[Luca Coelho]

Hi Dariusz,

On Fri, 2017-08-18 at 14:48 +0200, Dariusz Gadomski wrote:
> Hi,
> 
> There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware [1].
> I am unaware how that works exactly behind the scenes (except for some hints at
> [2]), but I have noticed that with that setting set to “Deny” I am observing
> issues when trying to connect from a machine with an Intel 8260 on a 4.10.0
> kernel - all connection attempts lead to failure.
> 
> I have managed to obtain some captured packets from that attempt as well as
> from a successful attempt (a machine with Broadcom bcm43224). What I have
> noticed is that AP puts the P2P IE in the beacon frames and when 8260 sends a
> probe request it also puts a P2P IE element in it. No response from the AP is
> ever transmitted.
> 
> In case of the Broadcom-based device the probe request does not contain P2P IE
> and it is able to correct normally. My understanding of this issue is that the
> AP makes the decision to temporarily blacklist the client after receiving a P2P
> IE from it.
> 
> I have made an additional test by commenting out the P2P interface types from
> iwlwifi/mvn/mac80211.c - using such kernel allowed the 8260 device to connect
> successfully.
> 
> I’m wondering if there’s a way of changing this behavior to enable the 8260 to
> connect to a network ‘secured’ in this way?  I would also appreciate some
> information about which behavior is correct (bcm43224 vs 8260) and is it
> specified anywhere in the Wi-Fi P2P specs (or anywhere else ftm)?

I have heard about this before.  The issue is that the Cisco AP doesn't
allow the 8260 to connect because it has the P2P IE in it.  But AFAICT
it is not against any specs to include this IE.  The Cisco AP is using
the IE as an indication that we are trying to connect as a P2P device,
which in this case we are not.

I'll try to dig the thread I had about this and take it again with our
system engineers to hear what they have to say about it.

In the meantime, I think it would be helpful if you could contact Cisco
about this issue as well.

--
Cheers,
Luca.

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

[Luca Coelho]

On Fri, 2017-08-18 at 20:16 +0300, Luca Coelho wrote:
> Hi Dariusz,
> 
> On Fri, 2017-08-18 at 14:48 +0200, Dariusz Gadomski wrote:
> > Hi,
> > 
> > There is a “Wi-Fi Direct Client Policy” setting in some Cisco AP hardware [1].
> > I am unaware how that works exactly behind the scenes (except for some hints at
> > [2]), but I have noticed that with that setting set to “Deny” I am observing
> > issues when trying to connect from a machine with an Intel 8260 on a 4.10.0
> > kernel - all connection attempts lead to failure.
> > 
> > I have managed to obtain some captured packets from that attempt as well as
> > from a successful attempt (a machine with Broadcom bcm43224). What I have
> > noticed is that AP puts the P2P IE in the beacon frames and when 8260 sends a
> > probe request it also puts a P2P IE element in it. No response from the AP is
> > ever transmitted.
> > 
> > In case of the Broadcom-based device the probe request does not contain P2P IE
> > and it is able to correct normally. My understanding of this issue is that the
> > AP makes the decision to temporarily blacklist the client after receiving a P2P
> > IE from it.
> > 
> > I have made an additional test by commenting out the P2P interface types from
> > iwlwifi/mvn/mac80211.c - using such kernel allowed the 8260 device to connect
> > successfully.
> > 
> > I’m wondering if there’s a way of changing this behavior to enable the 8260 to
> > connect to a network ‘secured’ in this way?  I would also appreciate some
> > information about which behavior is correct (bcm43224 vs 8260) and is it
> > specified anywhere in the Wi-Fi P2P specs (or anywhere else ftm)?
> 
> I have heard about this before.  The issue is that the Cisco AP doesn't
> allow the 8260 to connect because it has the P2P IE in it.  But AFAICT
> it is not against any specs to include this IE.  The Cisco AP is using
> the IE as an indication that we are trying to connect as a P2P device,
> which in this case we are not.
> 
> I'll try to dig the thread I had about this and take it again with our
> system engineers to hear what they have to say about it.
> 
> In the meantime, I think it would be helpful if you could contact Cisco
> about this issue as well.

Also, as a workaround if you are really not interested in using P2P is
to start wpa_supplicant with “p2p_disabled=1” in the configuration. 
This should prevent the P2P IE from being sent.

--
Cheers,
Luca.

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

[Dariusz Gadomski]

On Fri, Aug 18, 2017 at 08:20:02PM +0300, Luca Coelho wrote:
Hello Luca,

Thank you and Johannes for looking into this.

> > I'll try to dig the thread I had about this and take it again with our
> > system engineers to hear what they have to say about it.

Any news about that thread by any chance?

> > In the meantime, I think it would be helpful if you could contact Cisco
> > about this issue as well.

I heard from them that since there's a P2P IE transmitted from the
client then the behavior is correct. They recommended switching the
option in the AP to xconnect-not-allow which is supposed to allow
P2P-capable devices to associate as long as they won't use P2P
functionality.

> Also, as a workaround if you are really not interested in using P2P is
> to start wpa_supplicant with “p2p_disabled=1” in the configuration. 
> This should prevent the P2P IE from being sent.

Unfortunately that didn't help. Although I was not able to run any
P2P-specific commands in wpa_cli (e.g. p2p_find, p2p_listen all
return FAIL) connecting to the AP in question kept failing.
Do you have any further hints on debugging this?

> --
> Cheers,
> Luca.

Thanks!
Dariusz

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

[Johannes Berg]

On Fri, 2017-08-18 at 20:16 +0300, Luca Coelho wrote:
> 
> I have heard about this before.  The issue is that the Cisco AP
> doesn't allow the 8260 to connect because it has the P2P IE in
> it.  But AFAICT it is not against any specs to include this IE.  The
> Cisco AP is using the IE as an indication that we are trying to
> connect as a P2P device, which in this case we are not.

I believe that this is technically incorrect: they're assuming that
because P2P IEs are included, the device is P2P *capable* - completely
unrelated to connecting as a P2P-client (vs. a regular BSS client).

Because the device is P2P capable, there's a policy decision in the
configuration to not allow these clients to connect. This is actually
described in sections 3.4.3/3.4.4 of the P2P spec, and we should
probably implement the recommendations there?

johannes