Re: [PATCH 1/2] dpp: relax requirement on IWD being in a disconnected state

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

On 7/19/24 1:19 PM, James Prestwood wrote:
> Initially this made sense and for a completely unconfigured device
> there is little to no downside to limiting IWD's state to
> disconnected (or autoconnect states).
>

What about periodic scanning?

> Where this poses a problem is if the device has been configured
> incorrectly, for example with an invalid PSK. IWD will continue to
> try and connect to the network, blocking DPP from ever being
> started and always returning busy. Even if you timed it perfectly
> to start DP between connection attempts it would be canceled right
> away when IWD tried connecting again.

As in station_get_connected_network() returns non NULL?

> 
> Instead we can relax this requirement by allowing DPP to start even
> if IWD is connecting, and only cancel DPP when IWD's state
> transitions to connnected. Since DPP effectively blocks the wiphy
> work queue once it is started it will prevent any further connection
> attempts until it completes.

But if iwd is connecting, station_get_connected_network() is true and we've 
already sent the connection request?  So, you're inserting DPP work which will 
run after the connection attempt fails?

Have you looked into how WSC does this?

> ---
>   src/dpp.c | 48 +++++++++++++++++++++++++++++++++++++++++++-----
>   1 file changed, 43 insertions(+), 5 deletions(-)

FYI, CI is failing the DPP test for this set.

Regards,
-Denis