On 07/11/2018 01:54 PM, Natsuki.Itaya(a)sony.com wrote:
Issue 1. Current API triggers WPS protocol sequence with specified
therefore, WPS fails if it initiates WPS with other than the specified Service.
- Multi-Band AP
+ AP executes WPS over multiple bands
- Multi-Credential AP
+ AP delivers multiple credentials in one WPS protocol sequence
- "Unconfigured AP"
+ AP generates credential when it triggers WPS, then sets the crediential
to its WLAN driver(it requires AP restart)
- Multilple APs concurrently starts WPS protocol
+ It's difficult for user to identify target AP (selected registrar flag
does not provide any hints)
- User needs to trigger WPS on AP first then let AP to set selected registrar
to identify target AP
+ It forces user to trigger WPS on AP side first, sometimes such sequence contradicts
with instruction manual
- Some AP vendors asks user to trigger WPS on STA first
Issue 2. Current API aggregates two phases - obtaining credentials and connecting.
For upper layer SW developers, we understand that it would be good if WPS protocol
can be triggered in one transaction. However, we observed that such transaction
fails in following scenarios.
- AP gets unstable after delivering credential to STA
+ In this case, STA sometimes fails to associate with such AP using obtained
+ In "Unconfigured AP" case, some APs restart after delivering credential
so STA needs to wait
- Current API does not distinguish between the error of protocol to obtain credentials
and the error to associate with AP
+ Therefore, STA needs to restart WPS sequence even if it successfully obtains
1) The patch adds a basic start/cancel WPS API to the technology API.
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).
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.
4) Please have a look at the coding style guidance and run your patch
through checkpatch.pl There are some easy to catch formatting issues
in your patch.