Comment 0 for bug 1718688

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