Thank you Denis for your answer.

> So in theory iwd should gracefully handle such scenarios.  For example:
> - Connect comes while already connected (network switch)
> - Disconnect comes when connecting (aborts the connect attempt)
> - Connect while connecting (aborts original attempt, starts new one)

> There may be situations where the timing between requests is so small that we 
> simply have to return an -EBUSY (net.connman.iwd.Busy).

> Is there a particular scenario which isn't working?
In my opinion, the fix shall be done at ConnMan level and will always be
necessary, as the disconnection is asynchronous, contrary to the connection.

One year ago, a similar patch was integrated for wpa_supplicant.
(cf https://lists.01.org/hyperkitty/list/connman@lists.01.org/thread/NSWBVTHYPKUDON6K66YPL2OWFY6UYOV2/)

It is easy to reproduce the issue, by switching quickly between two known
Wifi networks (W1 & W2), via the Service api. By quickly, I mean: one call shall
immediately follow the reply of the previous call.
In this case, the following steps happen:
1. Disconnection of current network (W1).
2. Connection to the new one (W2) failing with "net.connman.iwd.Failed"
dbus error in cm_network_connect_cb, probably due to the fact that W1
disconnection was not already completed, aborting connection to W2.


Daniel, I have attached the v3 of the patch to be more compliant with the coding rules.
Please tell me both if you need additional information.


Best Regards,

Emmanuel