Re: [PATCH 1/3] doc: add documentation for P2P related API modifications

2013-05-15 Thread Simon Busch 

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

2013-05-15 Thread Simon Busch 

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

2013-05-15 Thread 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.

Regards

Marcel

___
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

2013-05-15 Thread Simon Busch 

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

Re: [PATCH 1/3] doc: add documentation for P2P related API modifications

2013-05-15 Thread 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.

that is for us to solve internally. Not a problem of the end user.

However the way this works is that the WiFi hardware needs to be activated. The 
actual wlan0 netdev for example can be happily be down for P2P operation. The 
phy itself does not have an on/off switch besides RFKILL.

So yes, rfkill WiFi, will also rfkill P2P, but so be it. We can still enforce 
WiFi off by keeping the wlan0 netdev down and only using P2P. It just means 
that if one of these technologies is enabled, the phy has to be enabled (and 
not rfkilled).

Regards

Marcel

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: D-Bus Timeouts

2013-05-15 Thread Daniel Wagner 

Hi,

On 01/14/2013 02:20 PM, Daniel Wagner wrote:

On 14.01.2013 14:08, Daniel Wagner wrote:

when something blocks:

connmanMonitor::servicesChanged
START: getServices !
getServices duration: 0.00296497344971
START: getServices !
getServices duration: 0.00302910804749
START: getServices !
getServices duration: 0.00310301780701
connmanMonitor::managerPropertyChanged
connmanMonitor::propertyChanged
connmanMonitor::managerPropertyChanged
connmanMonitor::propertyChanged
connmanMonitor::servicesChanged
START: getServices !
getServices duration: 0.00301790237427
START: getServices !
getServices duration: 0.00303387641907
START: getServices !
getServices duration: 6.37309789658


It seems that those timeout above are corresponding to the
append_nameservers() log entries

connmand[6082]: src/service.c:append_ipv4() ipv4 0x1be1210 state online
connmand[6082]: src/ipconfig.c:__connman_ipconfig_append_ipv4()
connmand[6082]: src/ipconfig.c:__connman_ipconfig_append_ipv4config()
connmand[6082]: src/service.c:append_ipv6() ipv6 0x1be1300 state idle
connmand[6082]: src/ipconfig.c:__connman_ipconfig_append_ipv6config()
connmand[6082]: src/service.c:append_nameservers() 0x1be6090
connmand[6082]: src/service.c:append_nameservers() servers[0] 192.168.100.4
connmand[6082]: src/service.c:append_nameservers() servers[1] 192.168.100.1
connmand[6082]: src/storage.c:storage_load() Loading /var/lib/connman/settings
connmand[6082]: src/service.c:append_proxy()
connmand[6082]: src/service.c:append_provider() 0x1bdc520 (nil)

Could it be that we block there?


After some more testing it is clear that ConnMan is working fine.

while sleep 1 ; do time connmanctrl services ; done

The Python script was running and in parallel the avove line did never 
block.


And whenever I saw the getServices() blockin, connmanctl just keept 
working fine.


From that I would say the problem is on the Python script side.

cheers,
daniel
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH] gdhcp: Handle dhcp_client-type == G_DHCP_IPV4LL

2013-05-15 Thread Patrik Flykt 
On Mon, 2013-05-13 at 13:13 -0700, Justin Maggard wrote:
 Clean up several places where dhcp_client-type == G_DHCP_IPV4LL is
 unhandled.

Applied, thanks!

In order not to make a mess out of the shared data structure memebers,
the dhcp and ll handling might need to be separate instances of the same
DHCP client data. And link local IPv4 can be set up only on one
interface at a time, which would make the ll struct static to the code
or something.

Do you think you'd have time to look into this?


Cheers,

Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH v3 07/12] session_policy_local: Rework policy file handling

2013-05-15 Thread Patrik Flykt 

Hi,

On Tue, 2013-05-07 at 10:27 +0200, Daniel Wagner wrote:
 From: Daniel Wagner daniel.wag...@bmw-carit.de
 
 The old assumption was that a config file is associtated
 with one session only. With introducing UID/GID support a policy
 might be used for several sessions. Furthermore, it was assumed
 that the file name is the key/ident to identify a session and
 a file containts exactly one policy.
 
 Here are the new rules for writing a policy file.
 
 - A valid file name contains letters or numbers and must have a '.policy'
   suffix.
 - The file name has not semantical meaning
 - A policy file may contain contain more than 1 policy
 - Each policy entry starts with 'policy_'
 - Each policy entry shall have one and exactly one valid key (e.g. selinux)
 
 And now some comments on the implementation. We have two main hash
 tables, file_hash and session_hash which own 'the file' respectively
 the session config. Additionally we have a hash table which connects a
 policy with a session (selinux_hash).
 ---
  plugins/session_policy_local.c | 402 
 ++---
  1 file changed, 258 insertions(+), 144 deletions(-)
 
 diff --git a/plugins/session_policy_local.c b/plugins/session_policy_local.c
 index 6cd876c..f0e4ff4 100644
 --- a/plugins/session_policy_local.c
 +++ b/plugins/session_policy_local.c
 @@ -46,33 +46,78 @@
  
  static DBusConnection *connection;
  
 -static GHashTable *policy_hash;
 -static GHashTable *session_hash;
 +static GHashTable *file_hash;/* (filename, policy_file) */
 +static GHashTable *session_hash; /* (connman_session, policy_config) */
 +
 +/* Global lookup table for mapping sessions to policies */
 +static GHashTable *selinux_hash; /* (lsm context, policy_group) */
  
  struct create_data {
   struct connman_session *session;
  };
  
 -struct policy_data {
 - int refcount;
 - char *ident;
 +/*
 + * A instance of struct policy_file is created per file in
 + * POLICYDIR.
 + */
 +struct policy_file {
 + /*
 +  * A valid file is a keyfile with one ore more groups. All
 +  * groups are keept in this list.
 +  */
 + GSList *groups;
 +};
  
 - struct connman_session *session;
 +struct policy_group {
 + char *selinux;
 +
 + /*
 +  * Each policy_group owns a config and is not shared with
 +  * sessions. Instead each session copies the valued from this
 +  * object.
 +  */
   struct connman_session_config *config;
 +
 + /* All 'users' of this policy. */
 + GSList *sessions;
 +};
 +
 +/* A struct policy_config object is created and owned by a session. */
 +struct policy_config {
 + char *selinux;
 +
 + /* The policy config owned by the session */
 + struct connman_session_config *config;
 +
 + /* To which policy belongs this policy_config */
 + struct connman_session *session;
 + /*
 +  * Points to the policy_group when a config has been applied
 +  * from a file.
 +  */
 + struct policy_group *group;
  };
  
 -static void cleanup_policy(gpointer user_data)
 +static void copy_session_config(struct connman_session_config *dst,
 + struct connman_session_config *src)
  {
 - struct policy_data *policy = user_data;
 + g_slist_free(dst-allowed_bearers);
 + dst-allowed_bearers = g_slist_copy(src-allowed_bearers);
 + dst-ecall = src-ecall;
 + dst-type = src-type;
 + dst-roaming_policy = src-roaming_policy;
 + dst-priority = src-priority;
 +}
  
 - DBG(policy %p, policy);
 +static void set_policy(struct policy_config *policy,
 + struct policy_group *group)
 +{
 + DBG(policy %p group %p, policy, group);
  
 - if (policy-config != NULL)
 - g_slist_free(policy-config-allowed_bearers);
 + group-sessions = g_slist_prepend(group-sessions, policy);
 + policy-group = group;
  
 - g_free(policy-ident);
 - g_free(policy-config);
 - g_free(policy);
 + copy_session_config(policy-config, group-config);
  }
  
  static char *parse_selinux_type(const char *context)
 @@ -111,51 +156,27 @@ static char *parse_selinux_type(const char *context)
   return ident;
  }
  
 -static struct policy_data *create_policy(const char *ident)
 +static struct policy_config *create_policy(void)
  {
 - struct policy_data *policy;
 + struct policy_config *policy;
  
 - DBG(ident %s, ident);
 -
 - policy = g_new0(struct policy_data, 1);
 - policy-refcount = 1;
 + policy = g_new0(struct policy_config, 1);
  
   DBG(policy %p, policy);
  
   policy-config = connman_session_create_default_config();
 - policy-ident = g_strdup(ident);
 -
 - g_hash_table_replace(policy_hash, policy-ident, policy);
  
   return policy;
  }
  
 -static struct policy_data *policy_ref(struct policy_data *policy)
 -{
 - DBG(%p %s ref %d, policy, policy-ident, policy-refcount + 1);
 -
 - __sync_fetch_and_add(policy-refcount, 1);
 -
 - return

Re: [PATCH v3 07/12] session_policy_local: Rework policy file handling

2013-05-15 Thread Daniel Wagner 

Hi Patrik,

On 05/15/2013 04:57 PM, Patrik Flykt wrote:

+static void recheck_sessions(void)
+{
+   GHashTableIter iter;
+   gpointer value, key;
+   struct policy_group *group = NULL;
+
+   g_hash_table_iter_init(iter, session_hash);
+   while (g_hash_table_iter_next(iter, key, value) == TRUE) {
+   struct policy_config *policy = value;
+
+   if (policy-group != NULL)
+   continue;
+
+   group = g_hash_table_lookup(selinux_hash, policy-selinux);
+   if (group != NULL)
+   set_policy(policy, group);
+
+   update_session(policy);


If group == NULL after the hash table lookup, do we need to
update_session(policy) even though nothing has changed or is it an
error?


Good catch. recheck_session() tries to find a configuration for a 
session which has no configuration attached yet. Therefore, if no 
configuration is found, nothing has to be done.


cheers,
daniel
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman