Page 1 of 1

Pi Zero W - wpa_supplicant - p2p-dev-wlan0 scanning stops connection to normal access point

Posted: Mon Oct 08, 2018 3:29 pm
by rogerjames99
I have been trying to get a Pi Zero W to connect to an access point at boot up. The configuration I use works well on a Pi 3 on board wifi. However when the same config is run on the Pi Zero W it fails to work. Examining what is going on using iw and wpa_cli it would seem that a scan has been started on a hidden P2P interface and this is stopping scans from working on the wlan0 interface.

iw dev shows the following:


Unamed/non-netdev interface
wdev 0x5
addr: 2e:04:29.....
type P2P-device
txpower 31.00dBm

Interface wlan0
ifindex 2
wdev 0x1
addr b0:27:eb:e5...
type managed
channel 1....

The version of wpa_supplicant in the current raspbian build is old (2.4) and ignores p2p_disabled setting (2.5+). So there is no way of stopping this. Trying to initiate a scan via wpa_cli on the wlan0 interface fails with "Failed to initiate scheduled scan" interspersed with CTRL_EVENT_SCAN_RESULTS from the scan that is still running on the other interface.

I would like to avoid having to rebuild wpa_supplicant from the up to date source.

Has anyone one else come across this?
Has anyone tried binding a network interface to that other mac address?
Has anyone got any other suggestions?



Re: Pi Zero W - wpa_supplicant - p2p-dev-wlan0 scanning stops connection to normal access point

Posted: Thu Oct 11, 2018 6:13 pm
by rogerjames99

I did a rebuild and ran a new version of wpa_supplicant. This allowed the connection to proceed. This unfortunately triggered another problem that I have come across before.

If you are trying to connect to any access point that has a short psk authentication timeout. For example support provided by hostapd(lots of router firmwares), wpa_supplicant has to respond to the nonce from the ap within the timeout, in the case of hostapd 100ms, or else the connection will be rejected with a timeout (code 16). The pi w seems to struggle to do this. Worse is to come, eventually all scan requests will be rejected with an error -23 file limit exceeded. This misleading. It is in fact a netlink error 23 "Object type does not match cache", whatever that means.

I suspect I am talking to myself here. But I will document it just in case snyone else wonders why the pi works with some aps and not others.