Sorry for my late reply.
1) The patch adds a basic start/cancel WPS API to the technology
The technology API doesn't give you any control over one device instead
it is a global API. So that renders the WPS API proposal to a global API
as well. So there is no additional control what device or frequency band
what so ever.
So how does the Mulit-Band, Mutlti-Credentia "Unconfigured" and Multiple
APs arguments fit into this proposal?
I think I get the problem about the ordering of WPS transactions. And we
might need a global start/cancel WPS API.
It seems I miss the point for Issue 2. Can you elaborate (maybe sequence
diagram) between the current design and the new API? I really wonder why
we can't handle errors via the agent as well.
2) The new proposed API seems to send D-Bus signals like PIN invalid
etc. (documentation missing?) Generally we avoid sending global signals,
instead we use a subscriber model (e.g. Agent API).
First, my proposed new API implementation followed the design of
the original patch
So that's the reason why I added the APIs to technology API and
used global signal.
So how does the Mulit-Band, Mutlti-Credentia "Unconfigured" and
Multiple APs arguments fit into this proposal?
To my understanding, current connman wps API conducts WPS procedure
with specific wifi service (SSID), which causes following issues
in those cases:
* Multi-band Operation:
- Many APs in the market operate WPS protocol over multi-band and
the SSID is different between band A and band B.
- However, current connman WPS implementation cannot specify
the operation band.
- Therefore, wpa_supplicant might proceed with conducting WPS
procedure and connecting to SSID (AP) which is different from
connman-specified SSID (service).
- In such case, connman disconnects WPS connection and judges as
* Multi credential delivery:
- There might be a case the AP distributes multiple credentials.
- In current implementation, the wpa_supplicant might select and
connect with the SSID which is different from specified service, too.
- connman disconnects this WPS connection and judges as a failure
* Unconfigured AP:
- The SSID and security setting would be updated after the WPS procedure.
- wpa_supplicant can connect with correct AP, but the SSID and setting
are different from specified service then connman disconnects with AP.
So, user would see such problems and since those scenarios are tested
during WPS certification testing, current connman cannot pass
the WPS certification.
Moreover, connman discards WPS credential when connman fails the association
with AP even after WPS protocol has successfully completed.
In this case, the user need retry WPS protocol, so I think WPS protocol and
connection should be separated.
Here is the summery of my proposal:
* connman should conduct WPS protocol without specifying SSID/band.
* connman should save a received credential into applicable wifi service
after completing WPS protocol.
* Then connman should notify WPS success with credential saved service list.
* After that, user selects and calls connect from service list.
* User also can retry the connection without retrying WPS even if
the connection to AP gets unstable.
3) The patch contains adds code to the wifi and supplicant driver. I
suggest you split this part of your work into separate patch series.
Thank you for
your suggestion. I split my patch into gsupplicant,
wifi_plugin, connmanctl and technology part.
4) Please have a look at the coding style guidance and run your
through checkpatch.pl There are some easy to catch formatting issues
in your patch.
Thanks, I've run checkpatch.pl for my patch, then fixed all
I'll send new patch series after this mail.