Public bug reported: 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 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Description changed: 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 + 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 + 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 -- 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
