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 (Denis Kenzior)
2. Re: [PATCH] ippool: Remove refcount on connman_ippool struct
(Daniel Wagner)
3. RE: [PATCH] add WPS patch ([email protected])
4. RE: [PATCH] add WPS patch ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Jul 2018 15:11:18 -0500
From: Denis Kenzior <[email protected]>
To: Daniel Wagner <[email protected]>, [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 Daniel,
> @iwd: I have lost a bit track what APIs iwd is offering for WPS. Is an
> API like proposed below possible to implement for iwd?
>
Here's the iwd WPS API. It is called WSC (Since the later specs are
actually named WiFi Simple Configuration)
https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/wsc-api.txt
Note that we only support STA mode WPS, however there is no separation
of obtaining credentials and connecting. It all happens in one
transaction. So once you invoke PushButton() you should be connected
after a while and the method call will return then.
Regards,
-Denis
------------------------------
Message: 2
Date: Wed, 11 Jul 2018 09:51:42 +0200
From: Daniel Wagner <[email protected]>
To: Nicolas Cornu <[email protected]>, Nicolas Cornu
<[email protected]>, [email protected]
Subject: Re: [PATCH] ippool: Remove refcount on connman_ippool struct
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
> First of all thank you. I'm not really aware of connman process, where
> is this patch applied?
They should appear on our repo on git.kernel.org, if ...
>
> I see nothing on master and it doesn't seem there is another branch out.
>
> Do you merge it on a local branch?
... I don't forget to push to the changes. I'll push it later, no access
right now to my home computer.
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 11 Jul 2018 11:41:52 +0000
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>, <[email protected]>,
<[email protected]>
Subject: RE: [PATCH] add WPS patch
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel,
Thanks for your feedback.
> The patch itself doesn't look too scary but it needs to be splitted into
> reasonable junks with commit messages which explains the change.
As suggested, please give us a few days to split patch into following topics
(with comments to explain each changes), then we'll again ask for your review.
- technology
- service
- plugin/wifi
- gSupplicant
- document
Regards,
n-itaya
> -----Original Message-----
> From: iwd [mailto:[email protected]] On Behalf Of Daniel Wagner
> Sent: Tuesday, July 10, 2018 2:27 PM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [PATCH] add WPS patch
>
> Hi,
>
> On 07/06/2018 12:21 PM, [email protected] wrote:
> > Hi,
> >
> > As ConnMan community previously discussed so, the WPS function has some
> issue.
> > https://lists.01.org/pipermail/connman/2018-January/022367.html
> >
> > In short, following technical issues / failure cases have been identified;
> > - Cannot start WPS protocol without specifying the target AP.
> > - WPS protocol sometimes fails with
> > + the AP that distributes multi-credentials
> > + Multi-band AP
> > + "Unconfigured" AP
> > Due to above issues, any products which uses ConnMan cannot pass WPS
> certification test.
> >
> > Please find the attached patch (based on v1.36) for further details.
> > We have used this patch for several months and have not seen any negative
> side effects.
>
> The patch itself doesn't look too scary but it needs to be splitted into
> reasonable junks with commit messages which explains the change.
> > To fix issues, we've separated current WPS protocol procedure into
> > a "credential distribution" and a "connection" processes.
> >
> > Proposed WPS API do only receive credential(s) delivered by WPS protocol.
> > The connman notify service(s) that receive WPS credential, an upper layer
> application,
> > like the connmanctl, must call "connect API" to the service.
> >
> > Please take a look at proposed patch, and give us your opinion
> > so that we can get an advice on how we should proceed to contribute this
> patch
> > into ConnMan official codebase for future releases.
>
> My main concern is the proposed API. I haven't really figured out how it
> fits
> into the current API. My first impression is that it doesn't fit with
> what we have already for WPS.
>
> @iwd: I have lost a bit track what APIs iwd is offering for WPS. Is an
> API like proposed below possible to implement for iwd?
>
>
> > index e3c1dcde..24b7f762 100644
> > --- a/doc/agent-api.txt
> > +++ b/doc/agent-api.txt
> > @@ -141,6 +141,12 @@ Fields string Name
> > In case of a RequestPeerAuthorization, this field
> will
> > be set as mandatory.
> >
> > + To use this in order to get connected to a given
> > + services is deprecated and should not be used.
> Methods
> > + Technology.Start_STA_WPS and
> Technology.Start_AP_WPS
> > + are provided by ConnMan and user should use those
> two
> > + instead.
> > +
> > string Username
> >
> > Username for WISPr authentication. This field
> will be
> > diff --git a/doc/technology-api.txt b/doc/technology-api.txt
> > index f22e9b29..75c1091d 100644
> > --- a/doc/technology-api.txt
> > +++ b/doc/technology-api.txt
> > @@ -40,6 +40,49 @@ Methods dict GetProperties()
> [deprecated]
> > via the PeersChanged signal from the manager
> > interface.
> >
> > + void Start_AP_WPS(string authentication)
> > +
> > + Start a WPS Session when the system is playing AP
> > + role (Tethering) in order to allow potential
> Ex-STAs
> > + to get connected by using WPS.
> > +
> > + The argument indicates the WPS authentication
> method
> > + which can be an empty string, if user wants to use
> > + push-button method, or a pin code if user wants
> to
> > + use the pin method.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors:
> [service].Error.InvalidArguments
> > +
> [service].Error.PermissionDenied
> > + [service].Error.NotSupported
> > +
> > + void Start_STA_WPS(string authentication)
> > +
> > + Start a WPS Session in STA role in order to be able
> > + to get connected with an Ex-AP with WPS
> capabilities.
> > +
> > + The argument indicates the WPS authentication
> method
> > + which can be an empty string, if user wants to use
> > + push-button method, or a pin code if user wants
> to
> > + use the pin method.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors:
> [service].Error.InvalidArguments
> > +
> [service].Error.OperationAborted
> > +
> [service].Error.OperationTimeout
> > + [service].Error.NotConnected
> > + [service].Error.NotSupported
> > +
> > + void Cancel_WPS()
> > +
> > + Cancel ongoing WPS session.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors: [service].Error.NotSupported
> > +
> > Signals PropertyChanged(string name, variant value)
> >
> > This signal indicates a changed value of the given
>
> Thanks,
> Daniel
> _______________________________________________
> iwd mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/iwd
------------------------------
Message: 4
Date: Wed, 11 Jul 2018 11:54:41 +0000
From: <[email protected]>
To: <[email protected]>, <[email protected]>
Cc: <[email protected]>, <[email protected]>
Subject: RE: [PATCH] add WPS patch
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi again,
> My main concern is the proposed API. I haven't really figured out how it
> fits
> into the current API. My first impression is that it doesn't fit with
> what we have already for WPS.
Please allow us to explain the rationale of proposed API - we believe that
current API design causes following issues.
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
Regards,
n-itaya
> -----Original Message-----
> From: iwd [mailto:[email protected]] On Behalf Of Daniel Wagner
> Sent: Tuesday, July 10, 2018 2:27 PM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [PATCH] add WPS patch
>
> Hi,
>
> On 07/06/2018 12:21 PM, [email protected] wrote:
> > Hi,
> >
> > As ConnMan community previously discussed so, the WPS function has some
> issue.
> > https://lists.01.org/pipermail/connman/2018-January/022367.html
> >
> > In short, following technical issues / failure cases have been identified;
> > - Cannot start WPS protocol without specifying the target AP.
> > - WPS protocol sometimes fails with
> > + the AP that distributes multi-credentials
> > + Multi-band AP
> > + "Unconfigured" AP
> > Due to above issues, any products which uses ConnMan cannot pass WPS
> certification test.
> >
> > Please find the attached patch (based on v1.36) for further details.
> > We have used this patch for several months and have not seen any negative
> side effects.
>
> The patch itself doesn't look too scary but it needs to be splitted into
> reasonable junks with commit messages which explains the change.
> > To fix issues, we've separated current WPS protocol procedure into
> > a "credential distribution" and a "connection" processes.
> >
> > Proposed WPS API do only receive credential(s) delivered by WPS protocol.
> > The connman notify service(s) that receive WPS credential, an upper layer
> application,
> > like the connmanctl, must call "connect API" to the service.
> >
> > Please take a look at proposed patch, and give us your opinion
> > so that we can get an advice on how we should proceed to contribute this
> patch
> > into ConnMan official codebase for future releases.
>
> My main concern is the proposed API. I haven't really figured out how it
> fits
> into the current API. My first impression is that it doesn't fit with
> what we have already for WPS.
>
> @iwd: I have lost a bit track what APIs iwd is offering for WPS. Is an
> API like proposed below possible to implement for iwd?
>
>
> > index e3c1dcde..24b7f762 100644
> > --- a/doc/agent-api.txt
> > +++ b/doc/agent-api.txt
> > @@ -141,6 +141,12 @@ Fields string Name
> > In case of a RequestPeerAuthorization, this field
> will
> > be set as mandatory.
> >
> > + To use this in order to get connected to a given
> > + services is deprecated and should not be used.
> Methods
> > + Technology.Start_STA_WPS and
> Technology.Start_AP_WPS
> > + are provided by ConnMan and user should use those
> two
> > + instead.
> > +
> > string Username
> >
> > Username for WISPr authentication. This field
> will be
> > diff --git a/doc/technology-api.txt b/doc/technology-api.txt
> > index f22e9b29..75c1091d 100644
> > --- a/doc/technology-api.txt
> > +++ b/doc/technology-api.txt
> > @@ -40,6 +40,49 @@ Methods dict GetProperties()
> [deprecated]
> > via the PeersChanged signal from the manager
> > interface.
> >
> > + void Start_AP_WPS(string authentication)
> > +
> > + Start a WPS Session when the system is playing AP
> > + role (Tethering) in order to allow potential
> Ex-STAs
> > + to get connected by using WPS.
> > +
> > + The argument indicates the WPS authentication
> method
> > + which can be an empty string, if user wants to use
> > + push-button method, or a pin code if user wants
> to
> > + use the pin method.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors:
> [service].Error.InvalidArguments
> > +
> [service].Error.PermissionDenied
> > + [service].Error.NotSupported
> > +
> > + void Start_STA_WPS(string authentication)
> > +
> > + Start a WPS Session in STA role in order to be able
> > + to get connected with an Ex-AP with WPS
> capabilities.
> > +
> > + The argument indicates the WPS authentication
> method
> > + which can be an empty string, if user wants to use
> > + push-button method, or a pin code if user wants
> to
> > + use the pin method.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors:
> [service].Error.InvalidArguments
> > +
> [service].Error.OperationAborted
> > +
> [service].Error.OperationTimeout
> > + [service].Error.NotConnected
> > + [service].Error.NotSupported
> > +
> > + void Cancel_WPS()
> > +
> > + Cancel ongoing WPS session.
> > +
> > + This method is supported only by WiFi technology.
> > +
> > + Possible Errors: [service].Error.NotSupported
> > +
> > Signals PropertyChanged(string name, variant value)
> >
> > This signal indicates a changed value of the given
>
> Thanks,
> Daniel
> _______________________________________________
> iwd mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/iwd
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 33, Issue 4
**************************************
