Send connman mailing list submissions to
        connman@lists.01.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        connman-requ...@lists.01.org

You can reach the person managing the list at
        connman-ow...@lists.01.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: [PATCH] add WPS patch (Daniel Wagner)


----------------------------------------------------------------------

Message: 1
Date: Thu, 19 Jul 2018 08:07:07 +0200
From: Daniel Wagner <w...@monom.org>
To: natsuki.it...@sony.com
Cc: connman@lists.01.org, i...@lists.01.org
Subject: Re: [PATCH] add WPS patch
Message-ID: <c5e56ef2-3eab-c0f1-c9a4-89356e255...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 07/11/2018 01:54 PM, natsuki.it...@sony.com wrote:
> Issue 1. Current API triggers WPS protocol sequence with specified Service,
> therefore, WPS fails if it initiates WPS with other than the specified 
> Service.
> 
> For example,
> - 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 credential
>    + 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 credential

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.

Thanks,
Daniel


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 33, Issue 7
**************************************

Reply via email to