| 2017-09-21 14:26:54 |
Dariusz Gadomski |
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
[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 |
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 |
|
