rogerjames99
Posts: 25
Joined: Fri Sep 28, 2012 2:58 pm

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

Mon Oct 08, 2018 3:29 pm

Hi,
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:

phy#0

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

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?

Cheers

Roger

rogerjames99
Posts: 25
Joined: Fri Sep 28, 2012 2:58 pm

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

Thu Oct 11, 2018 6:13 pm

EDITED!!!

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.

Return to “Raspbian”