Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
There is a setting available on selected Cisco hardware named "Wi-Fi Direct Client Policy". One of the allowed option there is 'not-allow'. It's intention is to block WiFi P2P capable devices from connecting to it. If a device trying to associate with an AP with this setting enabled is identified as "P2P capable" it gets blacklisted (I believe for a preconfigured time). More info about the option available at [1] and [2].
This leads to a situation that it is impossible to connect to certain APs using certain WiFi chips using iwlwifi driver. I was able to determine that this at least affects Intel 8260 chip.
What's going on on the WiFi level is:
The AP broadcasts beacon frames with P2P IE:
Tag: Vendor Specific: Wi-FiAll: P2P
Tag Number: Vendor Specific (221)
Tag length: 8
OUI: 50-6f-9a (Wi-FiAll)
Vendor Specific OUI Type: 9
P2P Manageability: Bitmap field 0x5
Attribute Type: P2P Manageability (10)
Attribute Length: 1
.... ...1 = P2P Device Management: 0x1
.... ..0. = Cross Connection Permitted: 0x0
.... .1.. = Coexistence Optional: 0x1
The client then sends a Probe Request, also with a P2P IE in it:
Tag: Vendor Specific: Wi-FiAll: P2P
Tag Number: Vendor Specific (221)
Tag length: 17
OUI: 50-6f-9a (Wi-FiAll)
Vendor Specific OUI Type: 9
P2P Capability: Device 0x25 Group 0x0
Attribute Type: P2P Capability (2)
Attribute Length: 2
Device Capability Bitmap: 0x25
.... ...1 = Service Discovery: 0x1
.... ..0. = P2P Client Discoverability: 0x0
.... .1.. = Concurrent Operation: 0x1
.... 0... = P2P Infrastructure Managed: 0x0
...0 .... = P2P Device Limit: 0x0
..1. .... = P2P Invitation Procedure: 0x1
Group Capability Bitmap: 0x00
.... ...0 = P2P Group Owner: 0x0
.... ..0. = Persistent P2P Group: 0x0
.... .0.. = P2P Group Limit: 0x0
.... 0... = Intra-BSS Distribution: 0x0
...0 .... = Cross Connection: 0x0
..0. .... = Persistent Reconnect: 0x0
.0.. .... = Group Formation: 0x0
Listen Channel: Operating Class 81 Channel Number 1
Attribute Type: Listen Channel (6)
Attribute Length: 5
Country String: XX\004
Operating Class: 81
Channel Number: 1
The AP never replies to that Probe Request and blacklists the device for a given period of time from all communication.
I was able to test a custom kernel with all P2P interfaces commented out from iwlwifi/
For instance this issue does not affect bcm43224 device running with brcm80211 - in this case the client device sends a Probe Request without the P2P IE. Despite it's is actually P2P-capable the AP does not recognize it as such and allows it to connect.
I have also started a mailing list thread about it [3].
What I think could fix it is either:
* making it behave more like the broadcom driver so it allows users to connect
* provide an user-friendly option of disabling p2p capabilites (including transmitting probe reuqests without P2P IE)
* as suggested on the ML [4] implement sections 3.4.3/3.4.4 of the WiFi Direct spec in the driver
According to my knowledge it affects all currently supported releases: Trusty, Xenial, Zesty plus Artful.
[1] https:/
[2] https:/
[3] https:/
[4] https:/
description: | updated |
tags: | added: kernel-bug-exists-upstream |
Changed in linux (Ubuntu): | |
status: | Incomplete → Confirmed |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1718688
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.