Functional test suite for connman
Hey everybody, I know there was once ago a functional test suite for connman as part of the Meego project. By searching through the web I just found the old meego references. Is there still a up to date and used functional test suite for connman available somehwere? regards, Simon ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] doc: Add API documentation about WiFi P2P Peer
Am 03.03.2014 09:17, schrieb Tomasz Bursztyka: Hi Simon, If available, the p2p technology will be instanciated. Note that it's fully dependant over wifi technology: wifi is the parent technology of p2p. If present, it will be possible to run a p2p peers discovery through p2p technology's Scan() method. Results will be provided through Manager API via GetPeers() method and/or PeeersChanged() signal. Right now we don't have any way to stop an ongoing scan. How do you want to handle the device discovery? Running it forever or just for a limited time? Second option. This should not be up to the application/management UI to know when to stop a scan. That said: once implementation will be there, the time frame will be documented (in an overview document) so whatever UI client will be able to know when it can re-request a scan (if it hasn't found a peer yet). This already the case with normal wifi scan actually, if a UI always want the refreshed list of wifi services: it needs to request a scan again (after first one, and the autoscan delays etc...) Sounds good to me. Just wanted to clarify this early. Furthermore it's also possible to put the device into a listening mode. While in listening mode it's possible to be found by other devices which can send connection requests. Here also we have to be smart, and hide that to the application: it should not be up to it to decide here. Imho, the only proper use case right now is when the device proposes some services. (if it does not serve anything, why will it want to be discovered?) So, when p2p service part will be specified: if an app add a service, then ConnMan will handle that and put the device in listening mode. But that will depend on the p2p service, as I noticed already: we might enforce being the GO in case of a WiDi/Mirracast sink service for instance. If we want to enforce becoming the GO we still need to say if this means creating an autonomous group and inviting possible clients or just setting an higher intent for the grouper owner negotiation to finally become the GO. But you're right that seems to be really a per service decision. Do you think we should hard code such decisions or make them configurable for the API user? regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] doc: add documentation for P2P related API modifications
Hey Tomasz, +boolean P2P [readwrite] + +This option allows to enable or disable the support +for P2P wireless network also known as WiFi Direct. + +When P2P is enabled scanning will scan for P2P peer +clients as well. Ok + +string P2PIdentifier [readwrite] + +This option allows to set the name of the device +used in P2P communication. Why not using system's hostname directly? At least as a default value. I remember we had the same discussion about wifi tethering SSID. Btw, you might add that this is available only for wifi technology. Good idea. Will add the mark as both properties being available for wifi technology only. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: API proposal for WiFi Direct support
Am 14.05.2013 16:17, schrieb Tomasz Bursztyka: Hi Simon, I am not completely aware of P2P stuff, so some of my comments might be bogus. Attached to this mail are three patches which outline the needed modifications to support group formation (with GO negotiation and autonoumous group support). It would be great if you can take a look at the patches and tell me what you think about the proposal. I tried to not break the API in any part and to build upon existing things. Technolgy and Service part looks ok to me. The group thing looks complicated: a lot to do in user side. Wouldn't it be possible simplify it? (default group, etc...) It might even be wise to solve the simplest use case of p2p, so without such group interface. A group needs a least one group owner. Thats called a autonoumous group. Peers can connect to a exiting group or connect to another peer to form a new group. So every time you have the abstraction of having a group and have to maintain it. Btw, in case a connman device get's invited to connect: how would it be handled? It probably requires agent stuff here. One thing which is missing is the service discovery functional. I am not sure wether this is something which belongs into connman or should be better provided by some other component. Underlying wifi daemon (wpa_supplicant) should handle that. I don't know how much wpa_supplicant supports about P2P though. Service discovery is implemented in wpa_supplicant but you have to use it. You can register services through wpa_supplicant which can be found by other peers to start a service discovery request to find services of other peers. wpa_supplicant has a quite good documentation on this at [1]. regards, Simon [1]: http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob;f=wpa_supplicant/README-P2P;h=8447a9044f67f606943729604e741f41bd1c09b2;hb=HEAD#l202 -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/3] doc: add documentation for P2P related API modifications
Am 15.05.2013 13:17, schrieb Marcel Holtmann: Hi Simon, +boolean P2P [readwrite] + +This option allows to enable or disable the support +for P2P wireless network also known as WiFi Direct. + +When P2P is enabled scanning will scan for P2P peer +clients as well. Ok + +string P2PIdentifier [readwrite] + +This option allows to set the name of the device +used in P2P communication. Why not using system's hostname directly? At least as a default value. I remember we had the same discussion about wifi tethering SSID. Btw, you might add that this is available only for wifi technology. Good idea. Will add the mark as both properties being available for wifi technology only. I would actually prefer we are not trying to overload the technology interface. Can we just create a new technology for P2P. Then on/off switch is simple and straight forward. Also the identifier can come from hostnamed and its pretty name. But isn't P2P bound to the wifi technology? Cause when wifi is off we can't enable P2P. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
API proposal for WiFi Direct support
Hey everybody, as mentioned some time ago I am interested in implementing WiFi direct support within connman. In the last week I took some time to go through the specification and try to map the concepts of WiFi direct to the connman DBus API. Attached to this mail are three patches which outline the needed modifications to support group formation (with GO negotiation and autonoumous group support). It would be great if you can take a look at the patches and tell me what you think about the proposal. I tried to not break the API in any part and to build upon existing things. One thing which is missing is the service discovery functional. I am not sure wether this is something which belongs into connman or should be better provided by some other component. regards, Simon ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/3] doc: add documentation for P2P related API modifications
--- doc/service-api.txt| 2 +- doc/technology-api.txt | 13 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/service-api.txt b/doc/service-api.txt index b33eb6f..4d85bae 100644 --- a/doc/service-api.txt +++ b/doc/service-api.txt @@ -161,7 +161,7 @@ Properties string State [readonly] string Type [readonly] - The service type (for example ethernet, wifi etc.) + The service type (for example ethernet, wifi, peer, etc.) This information should only be used to determine advanced properties or showing the correct icon diff --git a/doc/technology-api.txt b/doc/technology-api.txt index 9fe66b3..37aab0c 100644 --- a/doc/technology-api.txt +++ b/doc/technology-api.txt @@ -71,6 +71,19 @@ Properties boolean Powered [readwrite] advanced properties or showing the correct icon to the user. + boolean P2P [readwrite] + + This option allows to enable or disable the support + for P2P wireless network also known as WiFi Direct. + + When P2P is enabled scanning will scan for P2P peer + clients as well. + + string P2PIdentifier [readwrite] + + This option allows to set the name of the device + used in P2P communication. + boolean Tethering [readwrite] This option allows to enable or disable the support -- 1.8.1.2 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/3] doc: describe new group interface
---
doc/group-api.txt | 83 +
doc/manager-api.txt | 6
2 files changed, 89 insertions(+)
create mode 100644 doc/group-api.txt
diff --git a/doc/group-api.txt b/doc/group-api.txt
new file mode 100644
index 000..36a7c24
--- /dev/null
+++ b/doc/group-api.txt
@@ -0,0 +1,83 @@
+Group hierarchy
+=
+
+Servicenet.connman
+Interface net.connman.Group
+Object path[variable prefix]/{group0,group1,...}
+
+Methodsdict GetProperties()
+
+ Returns all global system properties. See the
+ properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.InvalidProperty
+
+ void Invite(object path)
+
+ Invite another peer to join this group.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ array{object,dict} GetPeers()
+
+ Returns a list of tuples with service object
+ path and dictionary of service properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+SignalsPeerAdded(object path, dict properties)
+
+ Signal that is sent when a new peer is added.
+
+ It contains the object path of the peer and
+ also its properties.
+
+ PeerRemoved(object path)
+
+ Signal that is sent when a peer has been disconnected
+ from this group.
+
+ It contains the object path of the peer.
+
+ PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string Name [readonly]
+
+ Network name (SSID) of the group.
+
+ string Passphrase [readwrite]
+
+ The passphrase clients need to join the group. This will
+ be only valid when the device is the owner of the group.
+
+ Clients connecting to a group will need the passphrase
to
+ be allowed to join the group.
+
+ boolean IsOwner [readonly]
+
+ Indicates wether the device is the owner of this group
or
+ not.
+
+ object path Owner [readonly]
+
+ Object path to the service object which is the owner of
+ this group.
+
+ Is only present when IsOwner is false.
+
+ boolean Persistent [readonly]
+
+ Indicates wether this group is persistent or not.group
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index ed23c8d..64e302a 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -145,6 +145,12 @@ Methodsdict GetProperties()
Possible Errors: [service].Error.InvalidArguments
+ object path CreateGroup()
+
+ Create a new group.
+
+ Possible Errors: [service].Error.InvalidArguments
+
SignalsTechnologyAdded(object path, dict properties)
Signal that is sent when a new technology is added.
--
1.8.1.2
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/3] doc: add overview description how p2p support works
--- doc/p2p-overview.txt | 62 1 file changed, 62 insertions(+) create mode 100644 doc/p2p-overview.txt diff --git a/doc/p2p-overview.txt b/doc/p2p-overview.txt new file mode 100644 index 000..a796df4 --- /dev/null +++ b/doc/p2p-overview.txt @@ -0,0 +1,62 @@ +P2P support overview + + +This document describes how P2P support inside connman works. + +Finding and listing other peers +=== + +P2P support is generally turned off inside connman. It has to be enable explicitly by +setting a property for for the wifi technology through the net.connman.Technology dbus +interface. + +net.connman.Technology.SetProperty(P2P, true) + +After P2P support is enabled connman will scan for peers whenever a scan for wifi networks +is scheduled. Either the scan is scheduled manually by the user through calling + +net.connman.Technology.Scan() + +or by background scanning. + +For every found peer a service object will be created and exported through dbus so it can +be accessed like any other service. + +Connecting to another peer +== + +TODO: Where do we set the intent to become the group owner? + +Connecting with another peer works through the Connect method of the net.connman.Service +interface. When a connection should be established one of the client starts the group +formation procedure through calling + +net.connman.Service.Connect() + +Internally the group formation procedure happens and authentication will done through +WPS and the connman agent interface as described in doc/agent-api.txt (WPS is mandatory in +this case). When the connection is established a group object (see doc/group-api.txt) will +be created and exported through dbus. The group can now be maintained through accessing +the several methods of the net.connman.Group interface. + +Inviting another peer to join a existing group +== + +When a group already exists it's possible to invite another avalible peer to join this +group. A invitation procedure can be initiated through calling the Invite method of the +net.connman.Group interface and supplying the dbus path to the service to invite. + +net.connman.Group.Invite(/service1) + +When the invitation process was successfully and the peer connected to the group the +net.connman.Group.PeerAdded signal is send. + +Creating a autonoumus group +=== + +It's possible to create a group without having any peer connected. This is called a +autonoumus group. Creating one is done through the net.connman.Manager interface: + +net.connman.Manager.CreateGroup() + +A group object is created and exported on dbus. -- 1.8.1.2 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Wifi direct support for connman
Hey everybody, I am pretty interested in wifi direct support within connman. I know there were some efforts to get a proof of concept implemented. Before I start over working on this I would like to ask wether anybody else is working on wifi direct support for connman so we can share our efforts instead of doing the same work twice. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Wifi direct support for connman
Hey Tomasz, Afaik nobody is working on it. Some people before have told having the same interest as you on wifi direct (or p2p) but no news since then. So patches are warmly welcome! Good to know. I already received the patches from Flávio Ceolin who did some proof of concept work. I rebased them to the latest version of connman and did some quick tests. From the first view it looks like there is a lot to do. I don't have an idea about how we can implement group management within connman. Will post when I have any news or first patches to discuss about. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH] Allow ethernet provision by interface name
Allowing provision by interface name can be helpful in some situations where
interface names never change. In all other situations where the interface name
is very
likely to change the MAC should still be used as identifier for provisioning.
---
doc/config-format.txt |2 ++
src/config.c | 27 +++
2 files changed, 29 insertions(+)
diff --git a/doc/config-format.txt b/doc/config-format.txt
index c255177..ca98995 100644
--- a/doc/config-format.txt
+++ b/doc/config-format.txt
@@ -56,6 +56,8 @@ Allowed fields:
interface is used. The byte values must have prefix 0 added,
the bytes must be separated by : char and its length must be
exactly 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 = 17 characters.
+- Interface: Name of the interface to configure. If MAC is also set it must
+ be the MAC address of the specified interface.
- Nameservers: Comma separated list of nameservers
- SearchDomains: Comma separated list of DNS search domains
- Timeservers: Comma separated list of timeservers
diff --git a/src/config.c b/src/config.c
index 05c654b..e94e835 100644
--- a/src/config.c
+++ b/src/config.c
@@ -66,6 +66,7 @@ struct connman_config_service {
char *ipv6_gateway;
char *ipv6_privacy;
char *mac;
+ char *interface;
char **nameservers;
char **search_domains;
char **timeservers;
@@ -108,6 +109,7 @@ static connman_bool_t cleanup = FALSE;
#define SERVICE_KEY_IPv6 IPv6
#define SERVICE_KEY_IPv6_PRIVACY IPv6.Privacy
#define SERVICE_KEY_MACMAC
+#define SERVICE_KEY_INTERFACE Interface
#define SERVICE_KEY_NAMESERVERSNameservers
#define SERVICE_KEY_SEARCH_DOMAINS SearchDomains
#define SERVICE_KEY_TIMESERVERSTimeservers
@@ -236,6 +238,7 @@ free_only:
g_free(config_service-ipv6_gateway);
g_free(config_service-ipv6_privacy);
g_free(config_service-mac);
+ g_free(config_service-interface);
g_strfreev(config_service-nameservers);
g_strfreev(config_service-search_domains);
g_strfreev(config_service-timeservers);
@@ -485,6 +488,12 @@ static connman_bool_t load_service_generic(GKeyFile
*keyfile,
service-mac = str;
}
+ str = g_key_file_get_string(keyfile, group, SERVICE_KEY_INTERFACE,
NULL);
+ if (str != NULL) {
+ g_free(service-interface);
+ service-interface = str;
+ }
+
str = g_key_file_get_string(keyfile, group, SERVICE_KEY_DOMAIN, NULL);
if (str != NULL) {
g_free(service-domain_name);
@@ -1106,6 +1115,24 @@ static void provision_service(gpointer key, gpointer
value,
return;
}
+ if (config-interface != NULL) {
+ struct connman_device *device;
+ const char *device_interface;
+
+ device = connman_network_get_device(network);
+ if (device == NULL) {
+ connman_error(Network device is missing);
+ return;
+ }
+
+ device_interface = connman_device_get_string(device,
Interface);
+
+ DBG(wants %s has %s, config-interface, device_interface);
+
+ if (g_ascii_strcasecmp(device_interface, config-interface) !=
0)
+ return;
+ }
+
if (g_strcmp0(config-type, wifi) == 0
type == CONNMAN_SERVICE_TYPE_WIFI) {
ssid = connman_network_get_blob(network, WiFi.SSID,
--
1.7.10.4
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: Pre-configuring an ethernet interface
Am 15.01.2013 16:00, schrieb Patrik Flykt: 1. Provide a default configuration .config file that sets the Ethernet defaults to something static instead of DHCPv4. This would be good to do some default factory configuration. This one is doable. I have a similar case where something like this is needed. Anyone already working on getting this implemented? regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
