Send connman mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [PATCH] add WPS patch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 07/11/2018 01:54 PM, [email protected] 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
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 33, Issue 7
**************************************
