On Fri, 2016-07-22 at 15:54 +0200, Jose Blanquicet wrote:
Two D-Bus methods were added to Technology Interface:
- void Start_AP_WPS(string authentication)
- void Start_STA_WPS(string authentication)
I'm trying to wrap my brains around the functionality added here. AFAIK
having these two functions in the technology API makes ConnMan able to
pass WiFi Alliance testing, right? And you also propose this for
regular use? But then the precedence between StartSTAWPS() and already
connected services are not that clear cut.
Drop '_' from method names.
With Start_STA_WPS method, WPS was completely detached from Service
and now ConnMan follows WiFi Alliance specifications. This patch
keeps current WPS implementation for compatibility support, but as
As far as I understand the above correctly, the point of this is to
have ConnMan the STA to "push the WPS button" first, right? And with
connman requesting WPS, the first AP to also enable WPS will then get
And the code for (manually) selecting a service which happens to be
broadcasting/announcing WPS, will automatically of course be connected
using WPS as before.
In case of multiple interfaces, Start_STA_WPS will prioritize the
STA-only interfaces if they exist, otherwise it will try on STA/AP
ones and only as last option it will use STA/AP/P2P interfaces.
If the STA/AP/P2P capability detection works, then yes. To be sure, AP
interfaces were marked such only after successfully setting up an AP
for tethering as the capabilities haven't been that perfectly provided
by wpa_supplicant in the past.
If the selected interface is already connected to a service or p2p
device, it will be disconnected and then the WPS Session will start
Hmm, disconnecting a connected interface sounds a bit unfortunate. Is
this encouraged by the WiFi Alliance specification? If yes, we might
not want not to do that, the STA or P2P connection in use can be more
important for the user than the opposite. From a ConnMan point of view
it is ok to return an -EBUSY equivalent over D-Bus if everything is
already in use. Opinions anyone?
Interfaces in AP mode (Tethering enabled) will not be taken into
account, they will be skipped.
Start_STA_WPS method will finished successfully when WPS-Credentials
are correctly received. From that point, all the notifications(error
or success) will be sent through the service corresponding to the
Shouldn't StartSTAWPS() return the service path on success or how else
is it known which service got connected via WPS? We do want to provide
the user with complete information on what the end result was.
In addition, by using Start_AP_WPS method, ConnMan now supports WPS
in AP mode (As registrar) which allows external devices get connect
by using WPS. For this method, if tethering is enabled it will start
a WPS Session on the corresponding tethering interface, otherwise it
will reply with a "PermissionDenied" error or "NotSupported" error
the interface has tethering enabled but it does not support WPS.
This leaves a time window when tethering is enabled using a passphrase,
but WPS is not active, which was the intention? Else one needs to have
an attribute for WiFi that can be set before tethering is enabled.
Technology documentation was updated.
doc/agent-api.txt | 6 +
doc/technology-api.txt | 35 +++++
Although small, these two should go into two different patches as they
gsupplicant/gsupplicant.h | 15 +++
gsupplicant/supplicant.c | 272 +++++++++++++++++++++++++-----------
Separate patch for the basic work on the low level supplicant methods.
include/technology.h | 10 ++
plugins/wifi.c | 322
src/connman.h | 1 +
src/peer.c | 5 +-
src/technology.c | 119 +++++++++++++++++
From here I'd single out the patches in plugins/wifi.c and
from the ones in technology. I hope plugins/wifi.c then handles all of
the WPS STA/peer things for the old and new cases with the same code.