Can't connect to a Cisco AP with Wi-Fi Direct Client Policy enabled

Bug #1718688 reported by Dariusz Gadomski on 2017-09-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

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.


description: updated

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
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to . 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.


Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-bug-exists-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Dariusz Gadomski (dgadomski) wrote :

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 <my_wifi> 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.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers