2:17 a.m.
Hello everybody,
We would like to propose a RFC to change the way to manage the WPS
connections. Following we present our proposal and the reasons for
suggesting it:
Current implementation of WPS connection requires to specify the service to
which the user wants to connect, and when the connection is going to
finalize, a verification is done in *handle_wps_completion* function to
ensure that the SSID of the AP actually being connected was the one
specified by the user. This violates the WiFi Alliance specification over
WPS and the WPS Certification plan because:
1. WiFi Alliance admits to certify devices that have no mean for the
user to choose an AP to connect to, they define them as "Client devices
with only a simple display or a fixed label containing a setup password"
(Pag. 12 of Wi-Fi Simple Configuration Technical Specification Version
2.0.5)
1. The WPS protocol includes the transition from un-configured to
configured state of the AP when the first Enrollee connects, some Access
Points change their SSID during this transition, that would cause the
ConnMan to invalidate the connection. A tipical example of such Access
Point is the Atheros used in test 5.4.2 of Wi-Fi CERTIFIED™ Wi-Fi Protected
Setup™ Interoperability Test Plan – Version 2.0.15
After having performed a detailed study of the wpa_supplicant
implementation for the WPS, we propose to implement a solution with the
following general characteristics:
1. The new implementation must keep current WPS implementation for
compatibility support, but as deprecated.
2. In order to meet the specifications of Wi-Fi Alliance and based on
what the WPS D-Bus Interface of wpa_supplicant offers (Documented in
https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps) we propose to add
two methods to the Technology D-Bus Interface: *StartWPS* and *CancelWPS*,
analogous to functions WPS.Start and WPS.Cancel provided by
wpa_supplicant. In this way there is no service specified enabling simple
devices to offer a very basic interface to the user for starting the WPS
session. Both methods would be supported only by WiFi technology.
3. On the other hand, some advanced WiFi modules expose more than one
network interface (one for P2P, one for STA, one for AP ..) that can be
active at the same time, and it is then desirable to not let connman
randomly choose on which start WPS, thus we propose also to add the
possibility to specify the interface over which either the start or cancel
action will be performed. This would not be a mandatory parameter in order
to keep the things easy for more simple systems.
Please find below the implementation proposal:
*StartWPS:*
Following the approach of wpa_supplicant, we propose to add the possibility
to choose which role to assume (enrollee, registrar), which authentication
type use (pin, pbc) and get back the pin to be used (if required), as well
as wpa_supplicant does. At this point, we can briefly define a possible
prototype of the method:
dict StartWPS(dict parameters)
Where the returned dictionary could be empty or composed by at most one
entry, which will be the just generated PIN by the wpa_supplicant, in case
it was requested. On the other hand, the function would receive a
dictionary with possible keys: “Ifname", "Role", "Type" and
"Pin"; where
“Ifame” is an optional parameters covering previous defined characteristic
for complex systems. Whereas, parameters "Role", "Type" and
"Pin" follow
exactly the same behavior of the table presented in
https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps for method Start
of fi.w1.wpa_supplicant1.Interface.WPS
Interface.
When the *StartWPS* method gets called, it should verify if interface was
specified through “Ifname” entry key. If so, WPS Session will be started in
that specific interface, otherwise we suggest to look for the first
available interface with the capabilities to start a WPS Session among the
device_list of the Wi-Fi Technology. If it is found, then use it, if not
return "[service].Error.NotSupported”.
Additionally, current implementation does not allow to start a WPS Session
when the device is playing as Access Point (Tethering). On the contrary,
wpa_supplicant does. Therefore, we propose to also add this possibility to
the new implementation. It would be possible if a Service D-Bus Object is
not required for starting a WPS Session, which would be true if the new
methods are added to the Technology D-Bus Interface, as we propose.
*CancelWPS:*
This function does not require for any particular parameter. So, we propose
to only continue giving the option to specify the interface. Therefore, the
possible prototype of the method would be:
void CancelWPS(dict parameters)
Where the received dictionary could be empty or composed by at most one
single entry if the user wants to specify the interface using the key
“Ifname”. If so, the *CancelWPS* function should cancel the ongoing WPS
Session running in that specific interface. Otherwise, we suggest to do it
over all the Device of the Wi-Fi Technology (device_list).
*Going into details of implementation*:
After having studied the ConnMan architecture we think to associate the WPS
concept to the Device Infrastructure because if we want to add the
possibility of specify the interface (“Ifname”), the Device is the
corresponding represents of a real device inside the ConnMan. Therefore, we
think it is the best choice. Additionally, *StartWPS* and *CancelWPS*
should be added to the device driver:
*static* *struct* connman_device_driver wifi_ng_driver = {
.name = "*wifi*",
.type = *CONNMAN_DEVICE_TYPE_WIFI*,
...
.start_wps = wifi_start_wps,
.cancel_wps = wifi_cancel_wps,
};
It means that WiFi plugging must implements both methods wifi_start_wps and
wifi_cancel_wps. In particular, wifi_start_wps will need to receive the WPS
parameters to then pass them to the ConnMan’s supplicant handler
(gsuppicant/supplicant.c), which is the only one that interacts directly
with the wpa_supplicant.
Next, the supplicant handler will call methods Start or Cancel of the
fi.w1.wpa_supplicant1.Interface.WPS
D-Bus Interface of the wpa_supplicant, with the required parameters. In
case the method Start returns the newly generated PIN it has to be
forwarded towards the Technology to then be added as an entry in the
directory that would be returned by the *StartWPS* method. It would imply
that we have to store the request message of the *StartWPS* method in order
to reply possibly with a the PIN generated by the wpa_supplicant. To do it,
we propose to store that message in the Device structure in order to be
coherent with the association we previously proposed between the WPS and
Device.
Once the WPS Session has been initiated, it could finalize successfully or
fail. The current implementation does not provide further information about
such a events. Given that, we propose to notify the following events (Just
the most commons):
- Success: WPS provisioning has finished successfully.
- Password Authentication Fail: When pin entered in the registrar was
wrong.
- PBC-Overlap: When an enrollee detects two registrars with PBC session
active.
We think to perform those notifications using a D-Bus Signal added to the
Technology Interface, let’s call it *WPSEvent*. It would simply indicate
when one of the described event takes place. We propose to just provide a
string with the name of the event: "success", "pwd-auth-fail" or
"pbc-overlap", following the wpa_supplicant notation. All this information
is already provided by the wpa_supplicant in the event
fi.w1.wpa_supplicant1.Interface.WPS.Event, thus it just need to be
forwarded to the Technology in order to be emitted.
In order to forward WPS events, we propose to follow the implementation of
the communication between the plug-in and the supplicant handler, it means
to use the callback mechanism adding a new callback:
*static* *const* GSupplicantCallbacks callbacks = {
...
.wps_event = wps_event,
};
Thus the wifi plug-in must implement the wps_event function that will
basically just call a Technology function that will emit the proposed
signal.
What do you think about our proposal? Of course, everybody is welcome to
give feedbacks and suggestions.
Best regards,
Jose Blanquicet
8:54 a.m.
Hi Jose,
Sorry for the long delay. Too much on my plate made me forgetting about
that proposal ;|
Hello everybody,
We would like to propose a RFC to change the way to manage the WPS
connections. Following we present our proposal and the reasons for
suggesting it:
Current implementation of WPS connection requires to specify the
service to which the user wants to connect, and when the connection is
going to finalize, a verification is done in /handle_wps_completion/
function to ensure that the SSID of the AP actually being connected
was the one specified by the user. This violates the WiFi Alliance
specification over WPS and the WPS Certification plan because:
1. WiFi Alliance admits to certify devices that have no mean for the
user to choose an AP to connect to, they define them as "Client
devices with only a simple display or a fixed label containing a
setup password" (Pag. 12 of Wi-Fi Simple Configuration Technical
Specification Version 2.0.5)
2. The WPS protocol includes the transition from un-configured to
configured state of the AP when the first Enrollee connects, some
Access Points change their SSID during this transition, that would
cause the ConnMan to invalidate the connection. A tipical example
of such Access Point is the Atheros used in test 5.4.2 of Wi-Fi
CERTIFIED™ Wi-Fi Protected Setup™ Interoperability Test Plan –
Version 2.0.15
After having performed a detailed study of the wpa_supplicant
implementation for the WPS, we propose to implement a solution with
the following general characteristics:
1. The new implementation must keep current WPS implementation for
compatibility support, but as deprecated.
2. In order to meet the specifications of Wi-Fi Alliance and based on
what the WPS D-Bus Interface of wpa_supplicant offers (Documented
in https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps) we
propose to add two methods to the Technology D-Bus Interface:
/StartWPS/ and /CancelWPS/, analogous to functions WPS.Start and
WPS.Cancel provided by wpa_supplicant. In this way there is no
service specified enabling simple devices to offer a very basic
interface to the user for starting the WPS session. Both methods
would be supported only by WiFi technology.
3. On the other hand, some advanced WiFi modules expose more than one
network interface (one for P2P, one for STA, one for AP ..) that
can be active at the same time, and it is then desirable to not
let connman randomly choose on which start WPS, thuswe propose
also to add the possibility to specify the interface over which
either the start or cancel action will be performed. This would
not be a mandatory parameter in order to keep the things easy for
more simple systems.
Please find below the implementation proposal:
_StartWPS:_
Following the approach of wpa_supplicant, we propose to add the
possibility to choose which role to assume (enrollee, registrar),
which authentication type use (pin, pbc) and get back the pin to be
used (if required), as well as wpa_supplicant does. At this point, we
can briefly define a possible prototype of the method:
dict StartWPS(dict parameters)
Where the returned dictionary could be empty or composed by at most
one entry, which will be the just generated PIN by the wpa_supplicant,
in case it was requested. On the other hand, the function would
receive a dictionary with possible keys: “Ifname", "Role",
"Type" and
"Pin"; where “Ifame” is an optional parameters covering previous
defined characteristic for complex systems. Whereas, parameters
"Role", "Type" and "Pin" follow exactly the same behavior
of the table
presented in https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps for
method Start of fi.w1.wpa_supplicant1.Interface.WPS Interface.
When the /StartWPS/ method gets called, it should verify if interface
was specified through “Ifname” entry key. If so, WPS Session will be
started in that specific interface, otherwise we suggest to look for
the first available interfacewith the capabilities to start a WPS
Session among the device_listof the Wi-Fi Technology. If it is found,
then use it, if not return "[service].Error.NotSupported”.
You don't want to expose ifname. ConnMan's idea is to hide the lower
level things like actual interfaces.
Of course my comment does not help when you need to mitigate which of
the 2+ wifi devices will actually run WPS.
You will have to figure out a way to make ConnMan smart about it.
Let's make things simpler on the other parameters too.
PBC/PIN for instance: make it one unique parameter. If filled in: it's a
PIN, if not: it's PBC.
No need then of type and pin. Just an "authentication" parameter.
Now about the role, it would be great to remove it also. It's trickier
but possible I think.
Thing is, user or UI itsels should not have to choose for the role. It's
an irrelevant information at this level.
ConnMan should be smart enough to figure out what's needed.
For instance, when it wants to connect to an AP, it's surely enrolee.
In case of P2P you can try that idea (I don't guaranty it's a working one):
There as already a logic in gsupplicant code that checks for actual WPS
being ran by some other end (this is currently used to avoid asking user
to run wps or provide a psk once he asked to connect a wifi service).
I am not entirely sure (wps is far away from me) but it's worth checking
in the IE that current WPS being broadcasted is a registrar or an
enrolee. That way: you can tell which role you need.
This works if only the other end has started WPS already.
Now in case you need to be the registrar. When tethering over wifi for
instance. You'll need a different approach.
A method dedicated to the AP mode?
Additionally, current implementation does not allow to start a WPS
Session when the device is playing as Access Point (Tethering). On the
contrary, wpa_supplicant does. Therefore, we propose to also add this
possibility to the new implementation. It would be possible if a
Service D-Bus Object is not required for starting a WPS Session, which
would be true if the new methods are added to the Technology D-Bus
Interface, as we propose.
_CancelWPS:_
This function does not require for any particular parameter. So, we
propose to only continue giving the option to specify the interface.
Therefore, the possible prototype of the method would be:
void CancelWPS(dict parameters)
Where the received dictionary could be empty or composed by at most
one single entry if the user wants to specify the interface using the
key “Ifname”. If so, the /CancelWPS/ function should cancel the
ongoing WPS Session running in that specific interface. Otherwise, we
suggest to do it over all the Device of the Wi-Fi Technology
(device_list).
Get rid of the ifname parameter. Just put no parameters and that's it.
ConnMan should be smart enough to check which device below is running
WPS and cancel those.
And btw: it's against the spec - afaik - to get more than 2 devices
around running WPS, so ConnMan should never start WPS on 2+ devices.
_Going into details of implementation_:
After having studied the ConnMan architecture we think to associate
the WPS concept to the Device Infrastructure because if we want to add
the possibility of specify the interface (“Ifname”), the Device is the
corresponding represents of a real device inside the ConnMan.
Therefore, we think it is the best choice. Additionally, /StartWPS/
and /CancelWPS/ should be added to the device driver:
*static**struct*connman_device_driverwifi_ng_driver = {
.name= "_wifi_",
.type= /CONNMAN_DEVICE_TYPE_WIFI/,
...
.start_wps= wifi_start_wps,
.cancel_wps= wifi_cancel_wps,
};
It means that WiFi plugging must implements both methods
wifi_start_wpsand wifi_cancel_wps. In particular, wifi_start_wpswill
need to receive the WPS parameters to then pass them to the ConnMan’s
supplicant handler (gsuppicant/supplicant.c), which is the only one
that interacts directly with the wpa_supplicant.
Next, the supplicant handler will call methods Start or Cancel of the
fi.w1.wpa_supplicant1.Interface.WPS D-Bus Interface of the
wpa_supplicant, with the required parameters. In case the method Start
returns the newly generated PIN it has to be forwarded towards the
Technology to then be added as an entry in the directory that would be
returned by the /StartWPS/ method. It would imply that we have to
store the request message of the /StartWPS/ method in order to reply
possibly with a the PIN generated by the wpa_supplicant. To do it, we
propose to store that message in the Device structure in order to be
coherent with the association we previously proposed between the WPS
and Device.
Once the WPS Session has been initiated, it could finalize
successfully or fail. The current implementation does not provide
further information aboutsuch a events. Given that, we propose to
notify the following events (Just the most commons):
* Success: WPS provisioning has finished successfully.
* Password Authentication Fail: When pin entered in the registrar
was wrong.
* PBC-Overlap: When an enrollee detects two registrars with PBC
session active.
We think to perform those notifications using a D-Bus Signal added to
the Technology Interface, let’s call it /WPSEvent/. It would simply
indicate when one of the described event takes place. We propose to
just provide a string with the name of the event: "success",
"pwd-auth-fail" or "pbc-overlap", following the wpa_supplicant
notation. All this information is already provided by the
wpa_supplicant in the event fi.w1.wpa_supplicant1.Interface.WPS.Event,
thus it just need to be forwarded to the Technology in order to be
emitted.
Either it's a success or a failure, and nobody above ConnMan cares about
the exact reason.
No need of any event. Just make StartWPS returning a end status, that's
it. No need of any signal.
In order to forward WPS events, we propose to follow the
implementation of the communication between the plug-in and the
supplicant handler, it means to use the callback mechanism adding a
new callback:
*static**const*GSupplicantCallbackscallbacks = {
...
.wps_event= wps_event,
};
Thus the wifi plug-in must implement the wps_eventfunction that will
basically just call a Technology function that will emit the proposed
signal.
What do you think about our proposal? Of course, everybody is welcome
to give feedbacks and suggestions.
Tomasz
6:20 a.m.
New subject: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hello Tomasz,
Thank you very much for your feedback. For this proposal we based on this assumption: we
are talking about DBUS interfaces, these are not directly the interface the end user will
need to understand, in between there must be and application for shell/graphical UI =>
here the developer may not be a WiFi expert, so we put all the parameters of StartWPS and
CancelWPS optional (except authentication), and connman will try to figure out an
automatic behavior => this already goes in the direction you proposed
On the other hand the automatic behavior may not suit all cases and an expert developer
may know how to manage several WiFi interfaces (in our case three, STA, P2P and AP) =>
in this case the optional parameters can come in handy.
"Ifname" : optional, meaning it can be empty, but with it we don't need
other methods when the UI needs to choose between STA-WPS or AP-WPS, or there is a P2P
interface that can be used also as an alternative STA or AP with WPS
"Type" and "Pin" you are proposing to have only one parameter
"authentication" but when the device with connman is enrollee it must show a PIN
to the user, not receive one: then we need to have two parameters (Type, PIN) like we
propose, or if you prefer only one (Authentication) it must be parsed in the following
way:
- A string like "PIN" which means the connman must provide a PIN to the
GUI so that the user can enter it in the other device (normally the AP)
- A string containing a number like "12345678" which means this is the
PIN to be used
- Empty: means use PBC
"role" - optional, meaning it can be empty, but while for the STA I agree with
you it mostly is an enrollee, the AP is a more complicated system; why not offer the
possibility to the developer to choose the role if he wants (or if he needs)?
Then what do you think to reduce the parameters in the following way?
dict StartWPS(dict parameters)
input parameters:
"ifname" - optional
"authentication" - mandatory
"role" - optional
void CancelWPS(void)
Thanks,
Marco
Da: connman [mailto:connman-bounces@lists.01.org] Per conto di Tomasz Bursztyka
Inviato: martedì 31 maggio 2016 17:54
A: connman(a)lists.01.org
Oggetto: Re: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi Jose,
Sorry for the long delay. Too much on my plate made me forgetting about that proposal ;|
Hello everybody,
We would like to propose a RFC to change the way to manage the WPS connections. Following
we present our proposal and the reasons for suggesting it:
Current implementation of WPS connection requires to specify the service to which the user
wants to connect, and when the connection is going to finalize, a verification is done in
handle_wps_completion function to ensure that the SSID of the AP actually being connected
was the one specified by the user. This violates the WiFi Alliance specification over WPS
and the WPS Certification plan because:
1. WiFi Alliance admits to certify devices that have no mean for the user to choose an
AP to connect to, they define them as "Client devices with only a simple display or a
fixed label containing a setup password" (Pag. 12 of Wi-Fi Simple Configuration
Technical Specification Version 2.0.5)
1. The WPS protocol includes the transition from un-configured to configured state of
the AP when the first Enrollee connects, some Access Points change their SSID during this
transition, that would cause the ConnMan to invalidate the connection. A tipical example
of such Access Point is the Atheros used in test 5.4.2 of Wi-Fi CERTIFIED(tm) Wi-Fi
Protected Setup(tm) Interoperability Test Plan - Version 2.0.15
After having performed a detailed study of the wpa_supplicant implementation for the WPS,
we propose to implement a solution with the following general characteristics:
1. The new implementation must keep current WPS implementation for compatibility
support, but as deprecated.
2. In order to meet the specifications of Wi-Fi Alliance and based on what the WPS
D-Bus Interface of wpa_supplicant offers (Documented in
https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps) we propose to add two methods to
the Technology D-Bus Interface: StartWPS and CancelWPS, analogous to functions WPS.Start
and WPS.Cancel provided by wpa_supplicant. In this way there is no service specified
enabling simple devices to offer a very basic interface to the user for starting the WPS
session. Both methods would be supported only by WiFi technology.
3. On the other hand, some advanced WiFi modules expose more than one network interface
(one for P2P, one for STA, one for AP ..) that can be active at the same time, and it is
then desirable to not let connman randomly choose on which start WPS, thus we propose also
to add the possibility to specify the interface over which either the start or cancel
action will be performed. This would not be a mandatory parameter in order to keep the
things easy for more simple systems.
Please find below the implementation proposal:
StartWPS:
Following the approach of wpa_supplicant, we propose to add the possibility to choose
which role to assume (enrollee, registrar), which authentication type use (pin, pbc) and
get back the pin to be used (if required), as well as wpa_supplicant does. At this point,
we can briefly define a possible prototype of the method:
dict StartWPS(dict parameters)
Where the returned dictionary could be empty or composed by at most one entry, which will
be the just generated PIN by the wpa_supplicant, in case it was requested. On the other
hand, the function would receive a dictionary with possible keys: "Ifname",
"Role", "Type" and "Pin"; where "Ifame" is an
optional parameters covering previous defined characteristic for complex systems. Whereas,
parameters "Role", "Type" and "Pin" follow exactly the same
behavior of the table presented in https://w1.fi/wpa_supplicant/devel/dbus.html#dbus_wps
for method Start of fi.w1.wpa_supplicant1.Interface.WPS Interface.
When the StartWPS method gets called, it should verify if interface was specified through
"Ifname" entry key. If so, WPS Session will be started in that specific
interface, otherwise we suggest to look for the first available interface with the
capabilities to start a WPS Session among the device_list of the Wi-Fi Technology. If it
is found, then use it, if not return "[service].Error.NotSupported".
You don't want to expose ifname. ConnMan's idea is to hide the lower level things
like actual interfaces.
Of course my comment does not help when you need to mitigate which of the 2+ wifi devices
will actually run WPS.
You will have to figure out a way to make ConnMan smart about it.
Let's make things simpler on the other parameters too.
PBC/PIN for instance: make it one unique parameter. If filled in: it's a PIN, if not:
it's PBC.
No need then of type and pin. Just an "authentication" parameter.
Now about the role, it would be great to remove it also. It's trickier but possible I
think.
Thing is, user or UI itsels should not have to choose for the role. It's an irrelevant
information at this level.
ConnMan should be smart enough to figure out what's needed.
For instance, when it wants to connect to an AP, it's surely enrolee.
In case of P2P you can try that idea (I don't guaranty it's a working one):
There as already a logic in gsupplicant code that checks for actual WPS being ran by some
other end (this is currently used to avoid asking user to run wps or provide a psk once he
asked to connect a wifi service).
I am not entirely sure (wps is far away from me) but it's worth checking in the IE
that current WPS being broadcasted is a registrar or an enrolee. That way: you can tell
which role you need.
This works if only the other end has started WPS already.
Now in case you need to be the registrar. When tethering over wifi for instance.
You'll need a different approach.
A method dedicated to the AP mode?
Additionally, current implementation does not allow to start a WPS Session when the device
is playing as Access Point (Tethering). On the contrary, wpa_supplicant does. Therefore,
we propose to also add this possibility to the new implementation. It would be possible if
a Service D-Bus Object is not required for starting a WPS Session, which would be true if
the new methods are added to the Technology D-Bus Interface, as we propose.
CancelWPS:
This function does not require for any particular parameter. So, we propose to only
continue giving the option to specify the interface. Therefore, the possible prototype of
the method would be:
void CancelWPS(dict parameters)
Where the received dictionary could be empty or composed by at most one single entry if
the user wants to specify the interface using the key "Ifname". If so, the
CancelWPS function should cancel the ongoing WPS Session running in that specific
interface. Otherwise, we suggest to do it over all the Device of the Wi-Fi Technology
(device_list).
Get rid of the ifname parameter. Just put no parameters and that's it. ConnMan should
be smart enough to check which device below is running WPS and cancel those.
And btw: it's against the spec - afaik - to get more than 2 devices around running
WPS, so ConnMan should never start WPS on 2+ devices.
Going into details of implementation:
After having studied the ConnMan architecture we think to associate the WPS concept to the
Device Infrastructure because if we want to add the possibility of specify the interface
("Ifname"), the Device is the corresponding represents of a real device inside
the ConnMan. Therefore, we think it is the best choice. Additionally, StartWPS and
CancelWPS should be added to the device driver:
static struct connman_device_driver wifi_ng_driver = {
.name = "wifi",
.type = CONNMAN_DEVICE_TYPE_WIFI,
...
.start_wps = wifi_start_wps,
.cancel_wps = wifi_cancel_wps,
};
It means that WiFi plugging must implements both methods wifi_start_wps and
wifi_cancel_wps. In particular, wifi_start_wps will need to receive the WPS parameters to
then pass them to the ConnMan's supplicant handler (gsuppicant/supplicant.c), which is
the only one that interacts directly with the wpa_supplicant.
Next, the supplicant handler will call methods Start or Cancel of the
fi.w1.wpa_supplicant1.Interface.WPS D-Bus Interface of the wpa_supplicant, with the
required parameters. In case the method Start returns the newly generated PIN it has to be
forwarded towards the Technology to then be added as an entry in the directory that would
be returned by the StartWPS method. It would imply that we have to store the request
message of the StartWPS method in order to reply possibly with a the PIN generated by the
wpa_supplicant. To do it, we propose to store that message in the Device structure in
order to be coherent with the association we previously proposed between the WPS and
Device.
Once the WPS Session has been initiated, it could finalize successfully or fail. The
current implementation does not provide further information about such a events. Given
that, we propose to notify the following events (Just the most commons):
* Success: WPS provisioning has finished successfully.
* Password Authentication Fail: When pin entered in the registrar was wrong.
* PBC-Overlap: When an enrollee detects two registrars with PBC session active.
We think to perform those notifications using a D-Bus Signal added to the Technology
Interface, let's call it WPSEvent. It would simply indicate when one of the described
event takes place. We propose to just provide a string with the name of the event:
"success", "pwd-auth-fail" or "pbc-overlap", following the
wpa_supplicant notation. All this information is already provided by the wpa_supplicant in
the event fi.w1.wpa_supplicant1.Interface.WPS.Event, thus it just need to be forwarded to
the Technology in order to be emitted.
Either it's a success or a failure, and nobody above ConnMan cares about the exact
reason.
No need of any event. Just make StartWPS returning a end status, that's it. No need of
any signal.
In order to forward WPS events, we propose to follow the implementation of the
communication between the plug-in and the supplicant handler, it means to use the callback
mechanism adding a new callback:
static const GSupplicantCallbacks callbacks = {
...
.wps_event = wps_event,
};
Thus the wifi plug-in must implement the wps_event function that will basically just call
a Technology function that will emit the proposed signal.
What do you think about our proposal? Of course, everybody is welcome to give feedbacks
and suggestions.
Tomasz
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain proprietary,
confidential and/or legally protected information and is intended solely for the use of
the designated addressee(s) above. If you are not the intended recipient be aware that any
downloading, copying, disclosure, distribution or use of the contents of the above
information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the
sender at the email address above, delete the message from all mailboxes and any other
electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free.
Therefore we do not assure that this message is complete or accurate and we do not accept
liability for any errors or omissions in the contents of this message.
7:07 a.m.
New subject: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi Marco,
Thank you very much for your feedback. For this proposal we based on
this assumption: we are talking about DBUS interfaces, these are not
directly the interface the end user will need to understand, in
between there must be and application for shell/graphical UI => here
the developer may not be a WiFi expert, so we put all the parameters
of StartWPS and CancelWPS optional (except authentication), and
connman will try to figure out an automatic behavior => this already
goes in the direction you proposed
On the other hand the automatic behavior may not suit all cases and an
expert developer may know how to manage several WiFi interfaces (in
our case three, STA, P2P and AP) => in this case the optional
parameters can come in handy.
“Ifname" : optional, meaning it can be empty, but with it we don’t
need other methods when the UI needs to choose between STA-WPS or
AP-WPS, or there is a P2P interface that can be used also as an
alternative STA or AP with WPS
Still, ConnMan never uses ifnames as an entry point for a decision.
Actually, the only place where you will see an interface name is in the
description of a Service entry (Ethernet dict attribute).
This is enforced, you can't change that rule :) we don't want users or
UI code to mess up with interfaces directly.
Make it work for 1 device first.
For P2P, you could use an alternate method called "Pair()" maybe. The
role is decided during pairing anyway (if I remember well? this is so
far away...).
Let's see how to solve that for 2+ device later.
(devices could be ordered by their support: the device which supports
more technologies would be the first, etc...
ConnMan would loop on them, each time StartWPS() - or Pair if supported
- failed. Just a quick idea.)
"Type" and "Pin"you are proposing to have only
one parameter
“authentication” but when the device with connman is enrollee it must
show a PIN to the user, not receive one: then we need to have two
parameters (Type, PIN)
We never supported the registrar side on current WPS support in ConnMan
(as far as I remember at least).
So if the Agent is requesting about WPS, up to the UI to provide a PIN
the user would use if user wants to use PIN method.
like we propose, or if you prefer only one (Authentication) it must
be
parsed in the following way:
-A string like “PIN” which means the connman must provide a PIN to the
GUI so that the user can enter it in the other device (normally the AP)
-A string containing a number like “12345678” which means this is the
PIN to be used
-Empty: means use PBC
“role” – optional, meaning it can be empty, but while for the STA I
agree with you it mostly is an enrollee, the AP is a more complicated
system; why not offer the possibility to the developer to choose the
role if he wants (or if he needs)?
AP mode in ConnMan is a very simplistic one. Actually, wpa_s does not
provide much feature there as well (compared to hostapd).
You could stick with registrar and that's it.
If you want to differentiate, you could add a configuration entry in
main.conf (like APWPSMode=<registrar/enrollee> ? registrar would be default)
Less stuff to expose through DBus at least. I would be surprised people
really care about such option anyway.
Hope it clarifies things.
Br,
Tomasz
4:53 a.m.
New subject: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi Marco,
On Thu, 2016-06-09 at 16:07 +0200, Tomasz Bursztyka wrote:
Hi Marco,
> Thank you very much for your feedback. For this proposal we based
> on this assumption: we are talking about DBUS interfaces, these are
> not directly the interface the end user will need to understand, in
> between there must be and application for shell/graphical UI =>
> here the developer may not be a WiFi expert, so we put all the
> parameters of StartWPS and CancelWPS optional (except
> authentication), and connman will try to figure out an automatic
> behavior => this already goes in the direction you proposed
>
> On the other hand the automatic behavior may not suit all cases and
> an expert developer may know how to manage several WiFi interfaces
> (in our case three, STA, P2P and AP) => in this case the optional
> parameters can come in handy.
>
> “Ifname" : optional, meaning it can be empty, but with it we don’t
> need other methods when the UI needs to choose between STA-WPS or
> AP-WPS, or there is a P2P interface that can be used also as an
> alternative STA or AP with WPS
Still, ConnMan never uses ifnames as an entry point for a decision.
Actually, the only place where you will see an interface name is in
the description of a Service entry (Ethernet dict attribute).
This is enforced, you can't change that rule :) we don't want users
or UI code to mess up with interfaces directly.
Make it work for 1 device first.
For P2P, you could use an alternate method called "Pair()" maybe. The
role is decided during pairing anyway (if I remember well? this is so
far away...).
Let's see how to solve that for 2+ device later.
(devices could be ordered by their support: the device which supports
more technologies would be the first, etc...
ConnMan would loop on them, each time StartWPS() - or Pair if
supported - failed. Just a quick idea.)
I suppose this will be used after setting 'Tethering' true for a
technology. I think ConnMan can pick up a/the tethering WiFi device
which supports WPS once WPS is requested. Then no ifname is needed.
The P2P and STA only interfaces should be identifiable, there exists
code that does try to figure out AP support when tethering (see
e.g. 452fa8db3eb7e88fe93c93569f21884697f2d2c6 and where it ended up
after db79090b895f23544d54abbf230efadbae9ec13b).
> "Type" and "Pin" you are proposing to have
only one parameter
> “authentication” but when the device with connman is enrollee it
> must show a PIN to the user, not receive one: then we need to have
> two parameters (Type, PIN)
We never supported the registrar side on current WPS support in
ConnMan (as far as I remember at least).
So if the Agent is requesting about WPS, up to the UI to provide a
PIN the user would use if user wants to use PIN method.
For the AP case an empty PIN should once again mean "pushbutton", while
a PIN with a value is, well, a pin.
> like we propose, or if you prefer only one (Authentication) it
must
> be parsed in the following way:
> - A string like “PIN” which means the connman must provide
> a PIN to the GUI so that the user can enter it in the other device
> (normally the AP)
> - A string containing a number like “12345678” which means
> this is the PIN to be used
> - Empty: means use PBC
The pin needs to be set beforehand, there are no Agent method calls to
be done for this. And after setting a pin that same entity can
call StartWPS to get the procedure into a running state.
> “role” – optional, meaning it can be empty, but while for the
STA I
> agree with you it mostly is an enrollee, the AP is a more
> complicated system; why not offer the possibility to the developer
> to choose the role if he wants (or if he needs)?
AP mode in ConnMan is a very simplistic one. Actually, wpa_s does not
provide much feature there as well (compared to hostapd).
You could stick with registrar and that's it.
If you want to differentiate, you could add a configuration entry in
main.conf (like APWPSMode=<registrar/enrollee> ? registrar would be
default)
Less stuff to expose through DBus at least. I would be surprised
people really care about such option anyway.
Setting the precise role seems to be unnecessary for now. It can be
added once there is evidence that it won't work without. I'm not sure
anybody can master more than a pin and calling start and stop here :-)
Hope it clarifies things.
I hope my comments do so too.
Cheers,
Patrik
5:24 a.m.
New subject: R: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hello Patrik, Tomasz,
Thank you for your feedback. Then the proposal could be:
void Start_STA_WPS(string authentication)
void CancelWPS(void)
void Start_AP_WPS(string authentication)
I removed all parameters except authentication, assuming that connman will operate in this
way:
- when starting connman is informed by the wpa_supplicant of the interfaces that
support P2P => these will be always the last to be considered when Start_STA_WPS or
Start_AP_WPS are called, in case there is a failure (or WPS not supported) on the other
interfaces (STA and AP)
- if the system has multiple interfaces connman will try WPS STA on STA one for
first and not P2P one (that normally also supports STA), and the same for WPS AP that will
be tried on the tethering one, not STA or P2P. that is very probably what the user
wants.
- If there is only one WiFi interface supporting multiple roles (STA, AP, P2P)
a. Start_STA_WPS
i. If connected STA:
disconnect and then start a WPS STA session
ii. If connected P2P:
disconnect and then start a WPS STA session
iii. If tethering
enabled: disable tethering and start WPS STA session
b. Start_AP_WPS
i. Similar algorithm
of above but for AP
- Authenthication: Empty means PBC, a value means PIN number. This also means
that for enrollee role the UI must generate a valid PIN and provide it to both connman and
to the user so he can enter it in the AP.
- Roles: for STA it is enrollee for AP it is registrar; as requested it can be
extended to support other combination of roles in main.conf
What do you think?
Thanks,
Marco
-----Messaggio originale-----
Da: Patrik Flykt [mailto:Patrik.Flykt@linux.intel.com]
Inviato: venerdì 10 giugno 2016 13:54
A: Tomasz Bursztyka; MANIEZZO Marco (MM); connman(a)lists.01.org
Cc: Blanquicet-Melendez Jose (MM)
Oggetto: Re: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi Marco,
On Thu, 2016-06-09 at 16:07 +0200, Tomasz Bursztyka wrote:
Hi Marco,
> Thank you very much for your feedback. For this proposal we
based on
> this assumption: we are talking about DBUS interfaces, these are
not
> directly the interface the end user will need to understand, in
> between there must be and application for shell/graphical UI
=> here
> the developer may not be a WiFi expert, so we put all the
parameters
> of StartWPS and CancelWPS optional (except authentication), and
> connman will try to figure out an automatic behavior => this
already
> goes in the direction you proposed
> > On the other hand the automatic behavior may not suit all cases
and
> an expert developer may know how to manage several WiFi
interfaces
> (in our case three, STA, P2P and AP) => in this case the
optional
> parameters can come in handy.
> > “Ifname" : optional, meaning it can be empty, but with it
we don’t
> need other methods when the UI needs to choose between STA-WPS
or
> AP-WPS, or there is a P2P interface that can be used also as an
> alternative STA or AP with WPS
Still, ConnMan never uses ifnames as an entry point for a decision.
Actually, the only place where you will see an interface name is in
the description of a Service entry (Ethernet dict attribute).
This is enforced, you can't change that rule :) we don't want
users or
UI code to mess up with interfaces directly.
Make it work for 1 device first.
For P2P, you could use an alternate method called "Pair()"
maybe. The
role is decided during pairing anyway (if I remember well? this is
so
far away...).
Let's see how to solve that for 2+ device later.
(devices could be ordered by their support: the device which
supports
more technologies would be the first, etc...
ConnMan would loop on them, each time StartWPS() - or Pair if
supported - failed. Just a quick idea.)
I suppose this will be used after setting 'Tethering' true for a technology. I
think ConnMan can pick up a/the tethering WiFi device which supports WPS once WPS is
requested. Then no ifname is needed.
The P2P and STA only interfaces should be identifiable, there exists code that does try to
figure out AP support when tethering (see e.g. 452fa8db3eb7e88fe93c93569f21884697f2d2c6
and where it ended up after db79090b895f23544d54abbf230efadbae9ec13b).
> "Type" and "Pin" you are proposing to have
only one parameter
> “authentication” but when the device with connman is enrollee
it
> must show a PIN to the user, not receive one: then we need to
have
> two parameters (Type, PIN)
We never supported the registrar side on current WPS support in
ConnMan (as far as I remember at least).
So if the Agent is requesting about WPS, up to the UI to provide a
PIN
the user would use if user wants to use PIN method.
For the AP case an empty PIN should once again mean "pushbutton", while a PIN
with a value is, well, a pin.
> like we propose, or if you prefer only one (Authentication) it
must
> be parsed in the following way:
> - A string like “PIN” which means the connman must
provide
> a PIN to the GUI so that the user can enter it in the other
device
> (normally the AP)
> - A string containing a number like “12345678” which
means
> this is the PIN to be used
> - Empty: means use PBC
The pin needs to be set beforehand, there are no Agent method calls to be done for this.
And after setting a pin that same entity can call StartWPS to get the procedure into a
running state.
> “role” – optional, meaning it can be empty, but while for the
STA I
> agree with you it mostly is an enrollee, the AP is a more
> complicated system; why not offer the possibility to the
developer
> to choose the role if he wants (or if he needs)?
AP mode in ConnMan is a very simplistic one. Actually, wpa_s does
not
provide much feature there as well (compared to hostapd).
You could stick with registrar and that's it.
If you want to differentiate, you could add a configuration entry in
main.conf (like APWPSMode=<registrar/enrollee> ? registrar
would be
default)
Less stuff to expose through DBus at least. I would be surprised
people really care about such option anyway.
Setting the precise role seems to be unnecessary for now. It can be added once there is
evidence that it won't work without. I'm not sure anybody can master more than a
pin and calling start and stop here :-)
Hope it clarifies things.
I hope my comments do so too.
Cheers,
Patrik
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain proprietary,
confidential and/or legally protected information and is intended solely for the use of
the designated addressee(s) above. If you are not the intended recipient be aware that any
downloading, copying, disclosure, distribution or use of the contents of the above
information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the
sender at the email address above, delete the message from all mailboxes and any other
electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free.
Therefore we do not assure that this message is complete or accurate and we do not accept
liability for any errors or omissions in the contents of this message.
5:59 a.m.
New subject: R: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi,
On Thu, 2016-06-16 at 12:24 +0000, MANIEZZO Marco (MM) wrote:
void Start_STA_WPS(string authentication)
When this is needed for P2P, then this should be part of the P2P
technology API, right? With that modification no guessing is done, P2P
is used when when StartWPS() is called for the P2P technology. Same for
WiFi technology.
void CancelWPS(void)
void Start_AP_WPS(string authentication)
For AP one needs tethering turned on. So starting and stopping of AP
WPS should follow whether tethering is enabled for WiFi and again only
a call to to StartWPS() is needed. Or is there a situation where
tethering is enabled but another WiFi device is idle and one actually
wants the other WiFi device to activate STA WPS?
The role selection should by default go as enrollee for non-tethering
WiFi and registrar when tethering if the role is something one cares
about?
Cheers,
Patrik
7:03 a.m.
New subject: R: R: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi Patrik,
For P2P connection the WPS topic is completely separated because it relies on Peer.Connect
(that uses its WPS current code) while the methods below belong to Technology. But the P2P
interface, when not connected, may also support to be a STA or AP and if it is not the
only one WiFi interface in the system very probably the user doesn't want connman
starts WPS (AP or STA) on it if by chance it is the first coming in its hands :), so
connman will consider it only as last chance.
We are working with Marvell chipsets and they expose three separated interfaces for STA,
AP and P2P (capable of concurrent connections): then we need to distinguish STA WPS and AP
WPS. Anyway the same would happen if you have a laptop with embedded WiFi capable of STA
WPS and then you plug an usb dongle you want to use as AP WPS, for instance..
We would also add the event Technology.WPSEvent(string event) to signal at least
"success" or "pwd-auth-fail" (we can also add
"pbc-overlap").
Regards,
Marco
-----Messaggio originale-----
Da: Patrik Flykt [mailto:Patrik.Flykt@linux.intel.com]
Inviato: giovedì 16 giugno 2016 15:00
A: MANIEZZO Marco (MM); Tomasz Bursztyka; connman(a)lists.01.org
Cc: Blanquicet-Melendez Jose (MM)
Oggetto: Re: R: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Hi,
On Thu, 2016-06-16 at 12:24 +0000, MANIEZZO Marco (MM) wrote:
void Start_STA_WPS(string authentication)
When this is needed for P2P, then this should be part of the P2P technology API, right?
With that modification no guessing is done, P2P is used when when StartWPS() is called for
the P2P technology. Same for WiFi technology.
void CancelWPS(void)
void Start_AP_WPS(string authentication)
For AP one needs tethering turned on. So starting and stopping of AP WPS should follow
whether tethering is enabled for WiFi and again only a call to to StartWPS() is needed. Or
is there a situation where tethering is enabled but another WiFi device is idle and one
actually wants the other WiFi device to activate STA WPS?
The role selection should by default go as enrollee for non-tethering WiFi and registrar
when tethering if the role is something one cares about?
Cheers,
Patrik
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain proprietary,
confidential and/or legally protected information and is intended solely for the use of
the designated addressee(s) above. If you are not the intended recipient be aware that any
downloading, copying, disclosure, distribution or use of the contents of the above
information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the
sender at the email address above, delete the message from all mailboxes and any other
electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free.
Therefore we do not assure that this message is complete or accurate and we do not accept
liability for any errors or omissions in the contents of this message.
1760
days inactive
1860
days old
7 comments
4 participants
participants (4)
-
Jose Blanquicet -
MANIEZZO Marco (MM) -
Patrik Flykt -
Tomasz Bursztyka