WPS connection request replies time-out when it actually gets a driver error

[Jose Blanquicet]

Hi Jouni,

>> We are testing WPS by using wpa_supplicant v2.5 on Linux laptop and
>> CSR6030 chip. The interface indicates that it supports WPS but when we
>> try to connect using wps_pbc this is what we got:
>
>> > wps_pbc
>> OK
>> <3>CTRL-EVENT-SCAN-RESULTS
>> <3>WPS-AP-AVAILABLE
>> <3>CTRL-EVENT-SCAN-RESULTS
>> <3>WPS-AP-AVAILABLE-PBC
>> <3>Trying to associate with 14:cc:20:b7:53:27 (SSID='Digicom_TpLink'
>> freq=2462 MHz)
>> <3>Association request to the driver failed
>
> Do you happen to have any idea why that request is failing? Do you have
> a matching wpa_supplicant debug log with more details on what is the
> exact operation that fails and a possible error code from that
> operation?

The error happens in wpa_driver_wext_associate() when wpa_supplicant
is trying to set the SSID, specifically in wpa_driver_wext_set_ssid
where errno indicates "Input/output error":

csr1: Starting radio work 'connect'@0x1c0a3f0 after 0.040674 second wait
csr1: Trying to associate with 14:cc:20:b7:53:27
(SSID='Digicom_TpLink' freq=2462 MHz)
CTRL-DEBUG: ctrl_sock-sendmsg: sock=13 sndbuf=163840 outq=0 send_len=80
CTRL_IFACE monitor sent successfully to /tmp/wpa_ctrl_878-2\x00
csr1: Cancelling scan request
csr1: WPA: clearing own WPA/RSN IE
csr1: Automatic auth_alg selection: 0x1
WPS: Building WPS IE for (Re)Association Request
WPS:  * Version (hardcoded 0x10)
WPS:  * Request Type
WPS:  * Version2 (0x20)
WPS:  * Device Password ID (4)
csr1: WPA: clearing AP WPA IE
csr1: WPA: clearing AP RSN IE
csr1: WPA: clearing own WPA/RSN IE
csr1: State: SCANNING -> ASSOCIATING
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
netlink: Operstate: ifindex=6 linkmode=-1 (no change), operstate=5
(IF_OPER_DORMANT)
csr1: Determining shared radio frequencies (max len 1)
csr1: Shared frequencies (len=0): completed iteration
wpa_driver_wext_associate
wpa_driver_wext_set_drop_unencrypted
wpa_driver_wext_set_psk
ioctl[SIOCSIWESSID]: Input/output error
csr1: Association request to the driver failed
CTRL-DEBUG: ctrl_sock-sendmsg: sock=13 sndbuf=163840 outq=0 send_len=40
CTRL_IFACE monitor sent successfully to /tmp/wpa_ctrl_878-2\x00

>> ... It repeats during the walk time (2 minutus) timeout ...
>>
>> <3>WPS-TIMEOUT Requested operation timed out
>
>> The callback from WPS.Start method does not indicate any error thus
>> the upper layers will only receive a signal indicating WPS-TIMEOUT
>> after the 2 min when actually it was an error with the driver. Could
>> you confirm us that this is the desired behavior?
>
> For properly behaving drivers, yes, this operation is supposed to
> continue searching for an appropriate AP for two minutes and connect to
> it to complete the WPS provisioning step. This is especially important
> for WPS-PIN. That said, it might be possible to break out sooner from
> this loop in case of WPS-PBC in the specific case of having a single AP
> in scan results showing active PBC mode and couple of attempts to
> associate to that failing. Anyway, it sounds like the main issue to fix
> here is in the driver interaction rather than in trying to figure out
> workarounds in the WPS implementation within wpa_supplicant..
>
>> We suggest to follow the same behavior of the WPA2 connections, where
>> it only performs X attempts and then it stops and indicates a signal
>> reporting CONN_FAILED further than only indicated
>> CTR-EVENT-DISCONNECTED. In the case of WPS, then wpa_supplicant should
>> emit a signal (e.g. WPS.Event) indicating that the WPS Session fails.
>> Doing so, programs at upper layer will be able to distinguish between
>> a real WPS timeout and when there was an error like the one we got
>> with our driver. In this way those programs will have enough
>> information to avoid to retry on the same interface and try on another
>> which could successfully get connected.
>
> This would not be correct behavior for WPS in general since there is
> need to iterate through all the available WPS APs when using PIN config
> method. This can have multiple APs completely misbehaving and
> wpa_supplicant will still need to find the specific AP that has a WPS
> Registrar willing to complete provisioning with this Enrollee.

Understood, it makes sense for us. Like you said, we should focus on
the interaction with the driver but we still think that this kind of
driver failure should stop the procedure. Do you agree on this?

Regards,

Jose Blanquicet