[Kernel-packages] [Bug 1718688] Re: Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Since I don't have access to the actual Cisco hardware for testing I have been experimenting with hostapd lately. After rebuilding it with CONFIG_P2P_MANAGER=y I was able to reproduce similar behavior as observed with Cisco hw (except for blacklisting) and as described in WiFi P2P spec v1.7 section 3.4. I was able to prevent my laptop from transmitting any P2P IEs after disabling P2P capabilities with wpa_cli -i p2p_set disabled 1 This however is different from what may be observed with other WiFi devices/drivers (as mentioned in the description) and the final paragraph of [1] suggests that it may be something missing/broken in the driver. [1] 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: Confirmed 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_01010.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 a
[Kernel-packages] [Bug 1718688] Re: Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
** Tags added: kernel-bug-exists-upstream ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- 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: Confirmed 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_01010.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
[Kernel-packages] [Bug 1718688] Re: Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled
Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.14 kernel[0]. If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. Once testing of the upstream kernel is complete, please mark this bug as "Confirmed". Thanks in advance. [0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc2/ ** Changed in: linux (Ubuntu) Importance: Undecided => Medium -- 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_01010.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: http
