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. [PATCH] [Pacrunner]: use memmove() instead of g_memmove()
(Atul Anand)
2. [PATCH] [Pacrunner]: use memmove() instead of g_memmove()
(Atul Anand)
3. API to get List of Connected STA's to an AP's (Lamsoge, Abhijit)
4. R: [RFC] Wi-Fi Protected Setup (WPS) connection
(MANIEZZO Marco (MM))
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Jun 2016 02:14:51 +0530
From: Atul Anand <[email protected]>
To: [email protected]
Subject: [PATCH] [Pacrunner]: use memmove() instead of g_memmove()
Message-ID: <[email protected]>
g_memmove() has been deprecated since GLib 2.40.
Build fails with newer versions of GLib.
---
pacrunner/unit/test-pacrunner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pacrunner/unit/test-pacrunner.c b/pacrunner/unit/test-pacrunner.c
index 70e2dbe..f234a35 100644
--- a/pacrunner/unit/test-pacrunner.c
+++ b/pacrunner/unit/test-pacrunner.c
@@ -107,7 +107,7 @@ static gchar **_g_strappendv(gchar **str_array, const gchar
*str)
}
if (str_array) {
- g_memmove(result, str_array, length * sizeof(gchar *));
+ memmove(result, str_array, length * sizeof(gchar *));
memset(str_array, 0, length * sizeof(gchar *));
}
--
2.5.5
------------------------------
Message: 2
Date: Thu, 9 Jun 2016 03:06:40 +0530
From: Atul Anand <[email protected]>
To: [email protected]
Subject: [PATCH] [Pacrunner]: use memmove() instead of g_memmove()
Message-ID: <[email protected]>
g_memmove() has been deprecated since GLib 2.40.
Build fails with newer versions of GLib.
---
pacrunner/unit/test-pacrunner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pacrunner/unit/test-pacrunner.c b/pacrunner/unit/test-pacrunner.c
index 70e2dbe..f234a35 100644
--- a/pacrunner/unit/test-pacrunner.c
+++ b/pacrunner/unit/test-pacrunner.c
@@ -107,7 +107,7 @@ static gchar **_g_strappendv(gchar **str_array, const gchar
*str)
}
if (str_array) {
- g_memmove(result, str_array, length * sizeof(gchar *));
+ memmove(result, str_array, length * sizeof(gchar *));
memset(str_array, 0, length * sizeof(gchar *));
}
--
2.5.5
------------------------------
Message: 3
Date: Thu, 9 Jun 2016 12:42:39 +0000
From: "Lamsoge, Abhijit" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: API to get List of Connected STA's to an AP's
Message-ID:
<3261e8fc74193743a7498db5c1deb85ebd3d5...@hikawsexmb01.ad.harman.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Patrick/All,
I have a few queries after long time.
1) Does connman support list of connected station/client to AP?
2) If yes, how we can access list of connected station ?
3) If no, then how/where we can implement this feature?
I think it's quiet an important feature if it is not supported in connman.
Abhijit
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160609/f5295d92/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 9 Jun 2016 13:20:14 +0000
From: "MANIEZZO Marco (MM)" <[email protected]>
To: Tomasz Bursztyka <[email protected]>,
"[email protected]" <[email protected]>
Cc: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
Subject: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
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:[email protected]] Per conto di Tomasz Bursztyka
Inviato: marted? 31 maggio 2016 17:54
A: [email protected]
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160609/ba497813/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 8, Issue 10
**************************************
