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.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1718688
Title:
Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Status in linux package in Ubuntu:
Incomplete
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
Manageability Bitmap field: 0x05
.... ...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/mvm/mac80211.c - it was able to connect to the AP
without any issues.
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://supportforums.cisco.com/t5/security-and-network-management/wi-fi-direct-client-policy/td-p/2253033
[2]
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
[3] https://marc.info/?l=linux-wireless&m=150306048824814&w=2
[4] https://marc.info/?l=linux-wireless&m=150461784431430&w=2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1718688/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
