from:"Chengyi Zhao"

RE: [PATCH] service: Send changed type signal

2014-12-11 Thread Chengyi Zhao




Hi

> From: checkz...@hotmail.com
> To: connman@connman.net
> Subject: RE: [PATCH] service: Send changed type signal
> Date: Thu, 11 Dec 2014 13:34:08 +
> 
> Hi,
> 
> > > 
> > > This does not make any sense.
> > > The type of the previous default service or the new one has not changed.
> > > Sure, the previous service could have a different type than the new one, 
> > > but themselves
> > > they haven't changed their type.
> Yes, this service type haven't been changed.
> But, now users want to monitor the type changed signal of default service,I 
> think ConnMan should send the signal when the type of default service has 
> been changed.
> So I suggest that manager module can add the property 'Type' to provider the 
> type > of current default service and send the type changed signal of default 
> service.
> > 
> > if you want to know what is the current type of default service, you can
> > get that information from service properties. You just need to listen
> > the service PropertyChanged signals and get the type from there.
> Yes, I think so.
> But, when received the service PropertyChanged('State' property) signals, > I 
> found out I can't get the correct default service, > because 'service_list' 
> sometimes hasn't been sorted. 

To Jukka,
Users can listen the ServicesChanged signal of manager object, after received 
this signal, service_list has been sorted, and the first service is a default 
service, user can getthe first service type.
Thanks,Chengyi
  
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

RE: [PATCH] service: Send changed type signal

2014-12-11 Thread Chengyi Zhao

Hi,

> > 
> > This does not make any sense.
> > The type of the previous default service or the new one has not changed.
> > Sure, the previous service could have a different type than the new one, 
> > but themselves
> > they haven't changed their type.
Yes, this service type haven't been changed.
But, now users want to monitor the type changed signal of default service,I 
think ConnMan should send the signal when the type of default service has 
beenchanged.
So I suggest that manager module can add the property 'Type' to provider the 
type of current default service and send the type changed signal of default 
service.
> 
> if you want to know what is the current type of default service, you can
> get that information from service properties. You just need to listen
> the service PropertyChanged signals and get the type from there.
Yes, I think so.
But, when received the service PropertyChanged('State' property) signals, I 
found out I can't get the correct default service, because 'service_list' 
sometimeshasn't been sorted. 
Thanks,
Chengyi
  
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

[PATCH] service: Send changed type signal

2014-12-11 Thread Chengyi Zhao

From: Chengyi Zhao 

---
 src/service.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/src/service.c b/src/service.c
index 9bba227..6c8b2a2 100644
--- a/src/service.c
+++ b/src/service.c
@@ -183,7 +183,7 @@ const char *__connman_service_type2string(enum 
connman_service_type type)
 {
switch (type) {
case CONNMAN_SERVICE_TYPE_UNKNOWN:
-   break;
+   return "unknown";
case CONNMAN_SERVICE_TYPE_SYSTEM:
return "system";
case CONNMAN_SERVICE_TYPE_ETHERNET:
@@ -1423,9 +1423,30 @@ bool __connman_service_index_is_default(int index)
return __connman_service_get_index(service) == index;
 }
 
+static void type_changed(struct connman_service *service)
+{
+   const char *str;
+
+   if (!service)
+   return;
+
+   if (!allow_property_changed(service))
+   return;
+
+   str = __connman_service_type2string(service->type);
+   if (!str)
+   return;
+
+   connman_dbus_property_changed_basic(service->path,
+   CONNMAN_SERVICE_INTERFACE, "Type",
+   DBUS_TYPE_STRING, &str);
+}
+
 static void default_changed(void)
 {
struct connman_service *service = __connman_service_get_default();
+   enum connman_service_type old_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
+   enum connman_service_type new_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
 
if (service == current_default)
return;
@@ -1436,6 +1457,11 @@ static void default_changed(void)
 
__connman_service_timeserver_changed(current_default, NULL);
 
+   if (current_default)
+   old_type = current_default->type;
+   if (service)
+   new_type = service->type;
+
current_default = service;
 
if (service) {
@@ -1448,6 +1474,9 @@ static void default_changed(void)
}
 
__connman_notifier_default_changed(service);
+
+   if (old_type != new_type)
+   type_changed(service);
 }
 
 static void state_changed(struct connman_service *service)
-- 
1.9.1

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

[PATCH] ipconfig: Fix memory leak

2014-10-16 Thread Chengyi Zhao

From: Chengyi Zhao 

---
 src/ipconfig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ipconfig.c b/src/ipconfig.c
index ae70745..2e840a6 100644
--- a/src/ipconfig.c
+++ b/src/ipconfig.c
@@ -698,7 +698,7 @@ void __connman_ipconfig_newaddr(int index, int family, 
const char *label,
goto out;
 
if ((ipdevice->flags & (IFF_RUNNING | IFF_LOWER_UP)) != (IFF_RUNNING | 
IFF_LOWER_UP))
-   return;
+   goto out;
 
for (list = g_list_first(ipconfig_list); list;
list = g_list_next(list)) {
-- 
1.9.1

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

RE: [PATCH] service: Change service state before changing manager state

2014-09-03 Thread Chengyi Zhao

Hi Patrik,

> 
> > The manager state is a global connection state of the system,
> > and it is a result of evaluating various notification states.
> > 
> > In order to ensure the consistency of data, ConnMan should
> > change the service state before changing the manager state,
> > wheter to change local states or emitting remote signals.
> 
> What consistency are you after here? Is it the ordering between
> net.connman.Manager and net.connman.Service State properties? If yes, I

Yes, it is the ordering between net.connman.Manager and net.connman.Service 
State properties.

> believe that setting PreferredTechnologies will still send the Manager
> and Service states in the current order.

--- a/src/service.c
+++ b/src/service.c
@@ -4109,8 +4109,8 @@ static void apply_relevant_default_downgrade(struct 
connman_service *service)
if (def_service == service &&
def_service->state == CONNMAN_SERVICE_STATE_ONLINE) {
def_service->state = CONNMAN_SERVICE_STATE_READY;
-   __connman_notifier_leave_online(def_service->type);
state_changed(def_service);
+   __connman_notifier_leave_online(def_service->type);
}
 }

Because 'apply_relevant_default_downgrade' has been indirectly called by
'service_update_preferred_order'，if apply this patch, when setting 
PreferredTechnologies, net.connman.Service State properties will be changed 
before net.connman.Manager 
State property.

However, this patch is only a minor suggestion, you can ignore it.

Thanks,

Chengyi


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

[PATCH] service: Change service state before changing manager state

2014-08-28 Thread Chengyi Zhao

From: Chengyi Zhao 

The manager state is a global connection state of the system,
and it is a result of evaluating various notification states.

In order to ensure the consistency of data, ConnMan should
change the service state before changing the manager state,
wheter to change local states or emitting remote signals.
---
 src/service.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/service.c b/src/service.c
index f35f436..a178c5f 100644
--- a/src/service.c
+++ b/src/service.c
@@ -4109,8 +4109,8 @@ static void apply_relevant_default_downgrade(struct 
connman_service *service)
if (def_service == service &&
def_service->state == CONNMAN_SERVICE_STATE_ONLINE) {
def_service->state = CONNMAN_SERVICE_STATE_READY;
-   __connman_notifier_leave_online(def_service->type);
state_changed(def_service);
+   __connman_notifier_leave_online(def_service->type);
}
 }
 
@@ -5301,12 +5301,12 @@ static int service_indicate_state(struct 
connman_service *service)
return result;
}
 
-   if (old_state == CONNMAN_SERVICE_STATE_ONLINE)
-   __connman_notifier_leave_online(service->type);
-
service->state = new_state;
state_changed(service);
 
+   if (old_state == CONNMAN_SERVICE_STATE_ONLINE)
+   __connman_notifier_leave_online(service->type);
+
if (new_state == CONNMAN_SERVICE_STATE_IDLE &&
old_state != CONNMAN_SERVICE_STATE_DISCONNECT) {
 
-- 
1.8.1.2

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

RE: [PATCH] service: Fix service disconnection when using the same index

2014-08-05 Thread Chengyi Zhao

Hi,

> > 
> >  src/service.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/src/service.c b/src/service.c
> > index 9406bc3..9740738 100644
> > --- a/src/service.c
> > +++ b/src/service.c
> > @@ -3957,6 +3957,16 @@ static DBusMessage *connect_service(DBusConnection 
> > *conn,
> >  if (service->pending)
> >  return __connman_error_in_progress(msg);
> >  
> > +if (is_connected(service)) {
> > +err = -EISCONN;
> > +goto done;
> > +}
> > +
> > +if (is_connecting(service)) {
> > +err = -EALREADY;
> > +goto done;
> > +}
> > +
> 
> This one will work as well. But to avoid confusion, we'd like to call
> __connman_service_connect() from everywhere in order to have one and
> only one place in the code where all necessary checks are done.
> 

Yes, agree with you.

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

RE: [PATCH] service: Fix service disconnection when using the same index

2014-08-05 Thread Chengyi Zhao

Hi Patrik,

> From: patrik.fl...@linux.intel.com
> To: connman@connman.net
> Subject: [PATCH] service: Fix service disconnection when using the same index
> Date: Tue, 5 Aug 2014 13:12:56 +0300
> 
> When a service is to be connected, other service(s) using the same
> interface will be disconnected. Fix the already connected or connecting
> situation by ignoring the service in question when seen in the list.
> 
> Simplify the index detection and signal a timeout when disconnect needs
> to happen first in order to indicate to the caller that the connect
> action needs to be redone.
> 

I think whether we can fix this issue with the following patch, ConnMan only 
checks the service state when entered the function "connect_service", please 
review.

 src/service.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/service.c b/src/service.c
index 9406bc3..9740738 100644
--- a/src/service.c
+++ b/src/service.c
@@ -3957,6 +3957,16 @@ static DBusMessage *connect_service(DBusConnection *conn,
 if (service->pending)
 return __connman_error_in_progress(msg);
 
+if (is_connected(service)) {
+err = -EISCONN;
+goto done;
+}
+
+if (is_connecting(service)) {
+err = -EALREADY;
+goto done;
+}
+
 for (list = service_list; list; list = list->next) {
 struct connman_service *temp = list->data;
 
@@ -3994,6 +4004,7 @@ static DBusMessage *connect_service(DBusConnection *conn,
 service->pending = NULL;
 }
 
+done:
 if (err < 0)
 return __connman_error_failed(msg, -err);

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

RE: [PATCH] service: Fix connection logic when called from D-Bus

2014-08-05 Thread Chengyi Zhao

Hi, 

> > root:/usr/lib/connman/test> ./test-connman connect 
> > wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
> > root:/usr/lib/connman/test> ./test-connman connect 
> > wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
> > net.connman.Error.Failed: Input/Output Error
> 
> There is actually an error yes, I could reproduce it easily.
> The loop should ignore the same service. But fix is a bit overkill, just 
> do this:
> 
> if (service == temp)
>  continue;
> 
> That should do the trick, at the beginning of the loop.
> 

Thanks Tomasz,

I think ConnMan can check the service state whether it is "connecting" or 
"connected" 
when entered the function "connect_service".

I will send a new patch for this issue, please review.

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

RE: [PATCH] service: Fix connection logic when called from D-Bus

2014-08-04 Thread Chengyi Zhao

Hi,

> 
> From: Chengyi Zhao 
> 
> When reconnected a same service which it has already been
> either connected or connecting before, this service doesn't
> need to be disconnected.
> ---
>  src/service.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/service.c b/src/service.c
> index 9406bc3..2421215 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -3968,6 +3968,9 @@ static DBusMessage *connect_service(DBusConnection 
> *conn,
>   if (!is_connecting(temp) && !is_connected(temp))
>   break;
>  
> + if (g_strcmp0(service->path, temp->path) == 0)
> + break;
> +

I'd like to explain why committed this path.

Do the following operations before applying this patch:

root:/usr/lib/connman/test> ./test-connman connect 
wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
root:/usr/lib/connman/test> ./test-connman connect 
wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
net.connman.Error.Failed: Input/Output Error

I think this is a issue that user gets the IO error and network will be 
diconnected when reconnected 
the same service.

Do the following operations after applying this patch:

root:/usr/lib/connman/test> ./test-connman connect 
wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
root:/usr/lib/connman/test> ./test-connman connect 
wifi_00dbdf140abe_54502d4c494e4b5f343736383741_managed_psk
net.connman.Error.AlreadyConnected: Already connected

Perhaps the better patch will fix this issue, please check.

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

RE: [PATCH] dhcp: Fixed Crash on Switching Network

2014-08-04 Thread Chengyi Zhao

Hi

> Date: Wed, 30 Jul 2014 15:51:54 +0300
> From: tomasz.burszt...@linux.intel.com
> To: saurav.b...@samsung.com; connman@connman.net
> Subject: Re: [PATCH] dhcp: Fixed Crash on Switching Network
> 
> Hi,
> 
> > Sometimes while switching network dhcp_initialize() fails because
> > interface is not up and hence dhcp->dhcp_client remains NULL. Here we
> > don't check return type of dhcp_initialize() and go on to call function
> > g_dhcp_client_start() and crash occurs.
> 
> Good catch, but this makes me think there is another bug: if the device 
> is down,
> connman should not even think of starting dhcp on it, so there might be 
> another issue
> to get fixed here. What version of connman are you using btw?

This issue can be found in ConnMan 1.24,
and you can reproduce it when repeatedly operated the following command:

./test-connman offlinemode on
./test-connman offlinemode off

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

[PATCH] service: Fix connection logic when called from D-Bus

2014-08-02 Thread Chengyi Zhao

From: Chengyi Zhao 

When reconnected a same service which it has already been
either connected or connecting before, this service doesn't
need to be disconnected.
---
 src/service.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/service.c b/src/service.c
index 9406bc3..2421215 100644
--- a/src/service.c
+++ b/src/service.c
@@ -3968,6 +3968,9 @@ static DBusMessage *connect_service(DBusConnection *conn,
if (!is_connecting(temp) && !is_connected(temp))
break;
 
+   if (g_strcmp0(service->path, temp->path) == 0)
+   break;
+
if (service->type != temp->type)
continue;
 
-- 
1.8.1.2

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

[PATCH] service: Fix connection logic when called from D-Bus

2014-08-02 Thread Chengyi Zhao

From: Chengyi Zhao 

When reconnected a same service which it has already been
either connected or connecting, this service doesn't need
to be disconnected.
---
 src/service.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/service.c b/src/service.c
index 9406bc3..7a3279a 100644
--- a/src/service.c
+++ b/src/service.c
@@ -3968,6 +3968,9 @@ static DBusMessage *connect_service(DBusConnection *conn,
if (!is_connecting(temp) && !is_connected(temp))
break;
 
+   if (!g_strcmp0(service->path, temp->path))
+   break;
+
if (service->type != temp->type)
continue;
 
-- 
1.8.1.2

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

Re: How to set the hardware clock from the current system time.

2014-06-26 Thread Chengyi Zhao

Hi,

FYI

Kevron Rees
<https://bugs.tizen.org/jira/secure/ViewProfile.jspa?name=tripzero> added a
comment - 16/May/14 6:12 AM

Using NTP, ConnMan keeps the system time properly synchronized to UTC


It doesn't. It only properly synchronizes when connected.

ConnMan has nothing to do with any variants of hardware clocks.


Why not? It seems rather incomplete to set the system time but rely on yet
another process to do the hardware clock sync. Why shouldn't connman handle
syncing?

https://bugs.tizen.org/jira/browse/TC-165
2014年3月24日 下午6:31于 "Patrik Flykt" 写道：

>
> Hi,
>
> On Mon, 2014-03-24 at 18:20 +0800, Chengyi Zhao wrote:
> > ConnMan can't set the hardware clock from the current system time,
> > when user has modified the system time, the time is unable to be saved
> > after reboot.
>
> That is correct.
>
> > Can the functionality of setting the hardware clock be added to
> > ConnMan? (It is similar to the shell "hwclock -w".)
>
> No. ConnMan has nothing to do with any variants of hardware clocks.
> Using NTP, ConnMan keeps the system time properly synchronized to UTC.
> It's up to the rest of the operating system to synchronize system time
> with the hardware clock when booting and shutting down.
>
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> https://lists.connman.net/mailman/listinfo/connman
>
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Please avoid ICMP Redirect when running VPN

2014-05-21 Thread Chengyi Zhao

Hi,

At first ,Please read the following information:
http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Redirect

If the VPN gateway is in the same subnet with the VPN client device(local
device),
please don't add the host route to the routing table of the client
device(local device).

Example:
VPN gateway IP: 192.168.1.105
Client device(local device) IP:   192.168.1.101
Router device IP: 192.168.1.1

Kernel IP routing table of Client device(local device):
Destination Gateway Genmask Flags   MSS Window  irtt
Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0  0
vpn0
10.8.0.110.8.0.5255.255.255.255 UGH   0 0  0
vpn0
10.8.0.50.0.0.0 255.255.255.255 UH0 0  0
vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U 0 0  0
eth0
192.168.1.1 0.0.0.0 255.255.255.255 UH0 0  0
eth0
*192.168.1.105   192.168.1.1 255.255.255.255 UGH   0 0  0
eth0*
202.103.24.68   192.168.1.1 255.255.255.255 UGH   0 0  0
eth0
202.103.44.150  192.168.1.1 255.255.255.255 UGH   0 0  0
eth0

Connman can't add the host route "192.168.1.105   192.168.1.1
255.255.255.255 UGH
0  0 0 eth0" to Kernel IP routing table in the client device,
otherwise, in some network environment, VPN client can't ping VPN gateway.

Thanks,

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

[PATCH] doc: Fixed some typos on coding style

2014-05-07 Thread Chengyi Zhao

From: Chengyi Zhao 

---
 doc/coding-style.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/coding-style.txt b/doc/coding-style.txt
index ae40180..97410ce 100644
--- a/doc/coding-style.txt
+++ b/doc/coding-style.txt
@@ -51,7 +51,7 @@ b = 3;
 
 The only exception to this rule applies when a variable is being allocated:
 array = g_try_new0(int, 20);
-if (array) // Correct
+if (!array)// Correct
return;
 
 
@@ -94,7 +94,7 @@ if (call->status == CALL_STATUS_ACTIVE ||
 
 3)
 gboolean sim_ust_is_available(unsigned char *service_ust, unsigned char len,
-   num sim_ust_service index) // wrong
+   enum sim_ust_service index) // wrong
 {
int a;
...
@@ -162,7 +162,7 @@ the expected behavior, and you may want to use g_try_malloc 
instead.
 
 Example:
 additional = g_try_malloc(len - 1);  // correct
-if (additional)
+if (!additional)
return FALSE;
 
 
-- 
1.8.1.2

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

Re: How to set the hardware clock from the current system time.

2014-03-25 Thread Chengyi Zhao

Hi Patrik,

> On Mon, 2014-03-24 at 18:20 +0800, Chengyi Zhao wrote:
> > ConnMan can't set the hardware clock from the current system time,
> > when user has modified the system time, the time is unable to be saved
> > after reboot.
>
> That is correct.
>
> > Can the functionality of setting the hardware clock be added to
> > ConnMan? (It is similar to the shell "hwclock -w".)
>
> No. ConnMan has nothing to do with any variants of hardware clocks.
> Using NTP, ConnMan keeps the system time properly synchronized to UTC.
> It's up to the rest of the operating system to synchronize system time
> with the hardware clock when booting and shutting down.
>
> Thanks a lot.

But Ossama has some ideas:

--

Patrik's comment assumes that automatic time updates are enabled in Connman
and/or NTP is configured. I don't believe his comment applies when
automatic updates are *disabled*. In that case, the user will set the time
manually. It seems reasonable to expect that time won't be lost at reboot.
Connman probably shouldn't provide a means to set the date and time
*manually* if it isn't going to save that time to the hardware clock.
Without the save to the hardware clock the manual date/time support in
Connman is essentially a redundant and unnecessary D-Bus call around the
settimeofday(2) <http://linux.die.net/man/2/settimeofday> system call.

If desired we can work around this limitation by having the native
date/time setting code set the time in the hardware clock via
/dev/rtc<http://linux.die.net/man/4/rtc>or through
timedated <http://www.freedesktop.org/wiki/Software/systemd/timedated/>.
Either way, the calling process will need the appropriate privilege (
CAP_SYS_TIME <http://man7.org/linux/man-pages/man7/capabilities.7.html>).
-

Cheers,

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

How to set the hardware clock from the current system time.

2014-03-24 Thread Chengyi Zhao

Hi,

ConnMan can't set the hardware clock from the current system time, when
user has modified the system time,
the time is unable to be saved after reboot.

Can the functionality of setting the hardware clock be added to ConnMan?
(It is similar to the shell "hwclock -w".)

Cheers,

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

Re: [PATCH] connection: Remove the VPN's host routing

2014-03-20 Thread Chengyi Zhao

Hi Patrik,

Do you think this is a useful patch?

---
>  src/connection.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index 1c43285..e98ccb5 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -980,12 +980,13 @@ void __connman_connection_gateway_remove(struct
> connman_service *service,
>
> if (do_ipv4 && data->ipv4_gateway &&
> data->ipv4_gateway->vpn && data->index >= 0)
> -   connman_inet_del_host_route(data->index,
> +
> connman_inet_del_host_route(data->ipv4_gateway->vpn_phy_index,
>
> data->ipv4_gateway->gateway);
>

The "data->ipv4_gateway->gateway" is VPN gateway, in other words, it is an
address of VPN server,
so the index should be a physics interface index
"data->ipv4_gateway->vpn_phy_index".

I have verified this issue sufficiently.

Thanks,

Chengyi

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

[PATCH] connection: Remove the VPN's host routing

2014-03-19 Thread Chengyi Zhao

From: Chengyi Zhao 

Based on the following routing table of the openvpn,
when disabled the VPN, ConnMan can't remove
the VPN's host routing "27.17.16.90 192.168.1.1 255.255.255.255",
in fact, ConnMan should remove it.

Enabled VPN:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 10.8.0.50.0.0.0 U   vpn0
10.8.0.110.8.0.5255.255.255.255 UGH vpn0
10.8.0.50.0.0.0 255.255.255.255 UH  vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Wrong):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   wlan0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Correct):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   wlan0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
---
 src/connection.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/connection.c b/src/connection.c
index 1c43285..e98ccb5 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -980,12 +980,13 @@ void __connman_connection_gateway_remove(struct 
connman_service *service,
 
if (do_ipv4 && data->ipv4_gateway &&
data->ipv4_gateway->vpn && data->index >= 0)
-   connman_inet_del_host_route(data->index,
+   connman_inet_del_host_route(data->ipv4_gateway->vpn_phy_index,
data->ipv4_gateway->gateway);
 
if (do_ipv6 && data->ipv6_gateway &&
data->ipv6_gateway->vpn && data->index >= 0)
-   connman_inet_del_ipv6_host_route(data->index,
+   connman_inet_del_ipv6_host_route(
+   data->ipv6_gateway->vpn_phy_index,
data->ipv6_gateway->gateway);
 
err = disable_gateway(data, type);
-- 
1.8.1.2

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

Re: Tethering questions

2014-03-18 Thread Chengyi Zhao

Hi,


2014-03-19 3:26 GMT+08:00 Homam Dabis :

> Ok thanks. One more question re tethering configuration:
>
> Everytime I am disabling an re-enabling tethering using dbus commands, I am
> getting a different IP range (192.168.0.1 -> 192.168.1.1 -> 192.168.?.1).
> Is this the way connman is suppose to behave?
>
> Yes, this is ConnMan design, maybe it has some issues.

If you'd like, please track this issue "https://01.org/jira/browse/CM-618";

Cheers,

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

What scenario does a application need to create two sessions?

2014-03-10 Thread Chengyi Zhao

Hi,

Would you like to explain what scenario a application needs to create two
sessions,
and how to create them?

Thanks,

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

Re: [PATCH 3/3] connection: Remove the VPN's host routing

2014-02-24 Thread Chengyi Zhao

Hi,

2014-02-24 15:47 GMT+08:00 Tomasz Bursztyka <
tomasz.burszt...@linux.intel.com>:

> Hi,
>
>
>  >Oh, sorry, committed messages are wrong, they should be:
>>>
>>  Disabled VPN (Wrong):
>>  Kernel IP routing table
>>  Destination Gateway Genmask Flags   Iface
>>  0.0.0.0   192.168.1.1 0.0.0.0 U wlan0
>>
>>  Disabled VPN (Correct):
>>  Kernel IP routing table
>>  Destination Gateway Genmask Flags   Iface
>>  0.0.0.0   192.168.1.1 0.0.0.0  Uwlan0
>>
>> I will commit the second version later.
>>
>
> These outputs are the same, I guess I made a mistake in your copy/paste?
>
>

This patch want to remove the host routing when disabled the VPN, in this
test case,
the VPN's host routing is:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
27.17.16.90 192.168.1.1255.255.255.255 UGH  wlan0

so the new messages are:

Based on the following routing table of the openvpn,
when disabled the VPN, ConnMan can't remove
the VPN's host routing "27.17.16.90 192.168.1.1 255.255.255.255",
in fact, ConnMan should remove it.

Enabled VPN:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.010.8.0.50.0.0.0 U   vpn0
10.8.0.1  10.8.0.5255.255.255.255 UGH vpn0
10.8.0.5  0.0.0.0  255.255.255.255 UH  vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Wrong):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   wlan0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Correct):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   wlan0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0

Thanks,

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

Re: [PATCH 2/3] connection: Set the specified gateway address

2014-02-23 Thread Chengyi Zhao

Hi,


2014-02-21 19:59 GMT+08:00 Patrik Flykt :

>
> Hi,
>
> On Fri, 2014-02-21 at 17:40 +0800, Chengyi Zhao wrote:
> > Based on the following routing table of the openvpn,
> > ConnMan set the wrong routing "0.0.0.0  0.0.0.0  0.0.0.0",
> > and a specified gateway address need be set instead of it.
> >
> > Wrong:
> > Kernel IP routing table
> > Destination Gateway Genmask Flags   Iface
> > 0.0.0.0 0.0.0.0 0.0.0.0 U   vpn0
>
> This does not immediately look wrong to me as vpn0 is a point-to-point
> device. A point-to-point device does not need a gateway entry.


Thanks a lot,
Yes, A point-to-point device does not need a gateway entry.
So "0.0.0.0  0.0.0.0  0.0.0.0" is correct for a point-to-point device.


> What kind
> of routing problems did you experience before this patch?
>
>
Only one reason：
The VPN server has already sent the gateway address to the client.
If so, I think ConnMan can set the gateway address to the default routing.

Thanks,

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

Re: [PATCH 3/3] connection: Remove the VPN's host routing

2014-02-21 Thread Chengyi Zhao

Hi,

2014-02-21 20:02 GMT+08:00 Patrik Flykt :

>
> Hi,
>
> On Fri, 2014-02-21 at 17:40 +0800, Chengyi Zhao wrote:
> > Disabled VPN (Wrong):
> > Kernel IP routing table
> > Destination Gateway Genmask Flags   Iface
> > 0.0.0.0 192.168.1.1 0.0.0.0 U   vpn0
> ...
> > Disabled VPN (Correct):
> > Kernel IP routing table
> > Destination Gateway Genmask Flags   Iface
> > 0.0.0.0 192.168.1.1 0.0.0.0 U   vpn0
>
> This routing table entry is now totally broken as it points to the VPN
> point-to-point device. I haven't really ever been notified about this
> kind of routing bug before, are you sure this was not accidentally
> introduced by the previous patches?
>
> Oh, sorry, committed messages are wrong, they should be:

Disabled VPN (Wrong):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0   192.168.1.1 0.0.0.0 U wlan0

Disabled VPN (Correct):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0   192.168.1.1 0.0.0.0  Uwlan0

I will commit the second version later.

Thanks,

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

[PATCH 1/3] inet: Add the new interface to set the specified gateway address

2014-02-21 Thread Chengyi Zhao

From: Chengyi Zhao 

Providing the new interface to set the default routing.
---
 include/inet.h |   2 ++
 src/inet.c | 101 +
 2 files changed, 103 insertions(+)

diff --git a/include/inet.h b/include/inet.h
index 37aed5f..0b51672 100644
--- a/include/inet.h
+++ b/include/inet.h
@@ -52,6 +52,7 @@ int connman_inet_add_network_route(int index, const char 
*host, const char *gate
 int connman_inet_del_network_route(int index, const char *host);
 int connman_inet_clear_gateway_address(int index, const char *gateway);
 int connman_inet_set_gateway_interface(int index);
+int connman_inet_set_gateway_address(int index, const char *gateway);
 int connman_inet_clear_gateway_interface(int index);
 bool connman_inet_compare_subnet(int index, const char *host);
 int connman_inet_set_ipv6_address(int index,
@@ -67,6 +68,7 @@ int connman_inet_del_ipv6_network_route(int index, const char 
*host,
 int connman_inet_del_ipv6_host_route(int index, const char *host);
 int connman_inet_clear_ipv6_gateway_address(int index, const char *gateway);
 int connman_inet_set_ipv6_gateway_interface(int index);
+int connman_inet_set_ipv6_gateway_address(int index, const char *gateway);
 int connman_inet_clear_ipv6_gateway_interface(int index);
 
 int connman_inet_add_to_bridge(int index, const char *bridge);
diff --git a/src/inet.c b/src/inet.c
index 1e513fd..2971c59 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -826,6 +826,66 @@ out:
return err;
 }
 
+int connman_inet_set_gateway_address(int index, const char *gateway)
+{
+   struct ifreq ifr;
+   struct rtentry rt;
+   struct sockaddr_in addr;
+   int sk, err = 0;
+
+   DBG("index %d gateway %s", index, gateway);
+
+   if (!gateway)
+   return -EINVAL;
+
+   sk = socket(PF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0);
+   if (sk < 0) {
+   err = -errno;
+   goto out;
+   }
+
+   memset(&ifr, 0, sizeof(ifr));
+   ifr.ifr_ifindex = index;
+
+   if (ioctl(sk, SIOCGIFNAME, &ifr) < 0) {
+   err = -errno;
+   close(sk);
+   goto out;
+   }
+
+   DBG("ifname %s", ifr.ifr_name);
+
+   memset(&rt, 0, sizeof(rt));
+   rt.rt_flags = RTF_UP | RTF_GATEWAY;
+
+   memset(&addr, 0, sizeof(addr));
+   addr.sin_family = AF_INET;
+   addr.sin_addr.s_addr = INADDR_ANY;
+   memcpy(&rt.rt_dst, &addr, sizeof(rt.rt_dst));
+
+   memset(&addr, 0, sizeof(addr));
+   addr.sin_family = AF_INET;
+   addr.sin_addr.s_addr = inet_addr(gateway);
+   memcpy(&rt.rt_gateway, &addr, sizeof(rt.rt_gateway));
+
+   memset(&addr, 0, sizeof(addr));
+   addr.sin_family = AF_INET;
+   addr.sin_addr.s_addr = INADDR_ANY;
+   memcpy(&rt.rt_genmask, &addr, sizeof(rt.rt_genmask));
+
+   if (ioctl(sk, SIOCADDRT, &rt) < 0 && errno != EEXIST)
+   err = -errno;
+
+   close(sk);
+
+out:
+   if (err < 0)
+   connman_error("Setting default gateway route failed (%s)",
+   strerror(-err));
+
+   return err;
+}
+
 int connman_inet_set_ipv6_gateway_interface(int index)
 {
struct ifreq ifr;
@@ -879,6 +939,47 @@ out:
return err;
 }
 
+int connman_inet_set_ipv6_gateway_address(int index, const char *gateway)
+{
+   struct in6_rtmsg rt;
+   int sk, err = 0;
+
+   DBG("index %d gateway %s", index, gateway);
+
+   if (!gateway)
+   return -EINVAL;
+
+   memset(&rt, 0, sizeof(rt));
+
+   if (inet_pton(AF_INET6, gateway, &rt.rtmsg_gateway) < 0) {
+   err = -errno;
+   goto out;
+   }
+
+   rt.rtmsg_flags = RTF_UP | RTF_GATEWAY;
+   rt.rtmsg_metric = 1;
+   rt.rtmsg_dst_len = 0;
+   rt.rtmsg_ifindex = index;
+
+   sk = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0);
+   if (sk < 0) {
+   err = -errno;
+   goto out;
+   }
+
+   if (ioctl(sk, SIOCADDRT, &rt) < 0 && errno != EEXIST)
+   err = -errno;
+
+   close(sk);
+
+out:
+   if (err < 0)
+   connman_error("Setting default IPv6 gateway error (%s)",
+   strerror(-err));
+
+   return err;
+}
+
 int connman_inet_clear_gateway_address(int index, const char *gateway)
 {
struct ifreq ifr;
-- 
1.8.1.2

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

[PATCH 3/3] connection: Remove the VPN's host routing

2014-02-21 Thread Chengyi Zhao

From: Chengyi Zhao 

Based on the following routing table of the openvpn,
when disabled the VPN, ConnMan can't remove
the VPN's host routing "27.17.16.90 192.168.1.1 255.255.255.255",
in fact, ConnMan should remove it.

Enabled VPN:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 10.8.0.50.0.0.0 U   vpn0
10.8.0.110.8.0.5255.255.255.255 UGH vpn0
10.8.0.50.0.0.0 255.255.255.255 UH  vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Wrong):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Disabled VPN (Correct):
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 192.168.1.1 0.0.0.0 U   vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
---
 src/connection.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/connection.c b/src/connection.c
index 370671e..fc6332a 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -168,6 +168,7 @@ static void get_gateway_cb(const char *gateway, int index, 
void *user_data)
goto out;
 
config->vpn_phy_index = index;
+   config->vpn_phy_ip = g_strdup(params->vpn_gateway);
 
DBG("vpn %s phy index %d", config->vpn_ip, config->vpn_phy_index);
 
@@ -982,13 +983,14 @@ void __connman_connection_gateway_remove(struct 
connman_service *service,
 
if (do_ipv4 && data->ipv4_gateway &&
data->ipv4_gateway->vpn && data->index >= 0)
-   connman_inet_del_host_route(data->index,
-   data->ipv4_gateway->gateway);
+   connman_inet_del_host_route(data->ipv4_gateway->vpn_phy_index,
+   data->ipv4_gateway->vpn_phy_ip);
 
if (do_ipv6 && data->ipv6_gateway &&
data->ipv6_gateway->vpn && data->index >= 0)
-   connman_inet_del_ipv6_host_route(data->index,
-   data->ipv6_gateway->gateway);
+   connman_inet_del_ipv6_host_route(
+   data->ipv6_gateway->vpn_phy_index,
+   data->ipv6_gateway->vpn_phy_ip);
 
err = disable_gateway(data, type);
 
-- 
1.8.1.2

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

[PATCH 2/3] connection: Set the specified gateway address

2014-02-21 Thread Chengyi Zhao

From: Chengyi Zhao 

Based on the following routing table of the openvpn,
ConnMan set the wrong routing "0.0.0.0  0.0.0.0  0.0.0.0",
and a specified gateway address need be set instead of it.

Wrong:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 0.0.0.0 0.0.0.0 U   vpn0
10.8.0.110.8.0.5255.255.255.255 UGH vpn0
10.8.0.50.0.0.0 255.255.255.255 UH  vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0

Correct:
Kernel IP routing table
Destination Gateway Genmask Flags   Iface
0.0.0.0 10.8.0.50.0.0.0 U   vpn0
10.8.0.110.8.0.5255.255.255.255 UGH vpn0
10.8.0.50.0.0.0 255.255.255.255 UH  vpn0
192.168.1.0 0.0.0.0 255.255.255.0   U   wlan0
192.168.1.1 0.0.0.0 255.255.255.255 UH  wlan0
27.17.16.90 192.168.1.1 255.255.255.255 UGH wlan0
---
 src/connection.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/connection.c b/src/connection.c
index 3e6e656..370671e 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -432,7 +432,8 @@ static void set_default_gateway(struct gateway_data *data,
 
if (do_ipv4 && data->ipv4_gateway &&
data->ipv4_gateway->vpn) {
-   connman_inet_set_gateway_interface(data->index);
+   connman_inet_set_gateway_address(data->index,
+   data->ipv4_gateway->vpn_ip);
data->ipv4_gateway->active = true;
 
DBG("set %p index %d vpn %s index %d phy %s",
@@ -447,7 +448,8 @@ static void set_default_gateway(struct gateway_data *data,
 
if (do_ipv6 && data->ipv6_gateway &&
data->ipv6_gateway->vpn) {
-   connman_inet_set_ipv6_gateway_interface(data->index);
+   connman_inet_set_ipv6_gateway_address(data->index,
+   data->ipv6_gateway->vpn_ip);
data->ipv6_gateway->active = true;
 
DBG("set %p index %d vpn %s index %d phy %s",
-- 
1.8.1.2

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

[PATCH 0/3] vpn: fix to handle the routing table for VPN

2014-02-21 Thread Chengyi Zhao

From: Chengyi Zhao 

After a VPN client has successfully connected the VPN server,
the client's routing table existed a error default routing.

In addition, after a VPN client has disconnected the VPN server,
the client's routing table existed a unnecessary VPN's host routing.

The following patchset will fix these issues.

Chengyi Zhao (3):
  inet: Add the new interface to set the specified gateway address
  connection: Set the specified gateway address
  connection: Remove the VPN's host routing

 include/inet.h   |   2 ++
 src/connection.c |  16 +
 src/inet.c   | 101 +++
 3 files changed, 113 insertions(+), 6 deletions(-)

-- 
1.8.1.2

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

Re: How to connect the l2tp VPN

2014-01-23 Thread Chengyi Zhao

Hi,


2014/1/23 Patrik Flykt 

>
> Hi,
>
> On Thu, 2014-01-23 at 14:17 +0800, Chengyi Zhao wrote:
> > I would like to connect the l2tp VPN via ConnMan, but  I can't connect
> > the xl2tp server, Please share following configure files to me:
> > connman-xl2tpd.conf
> > connman-ppp-option.conf
>
> You have to set up the l2tp parameters according to your network
> configuration, there is no generic config file that can work for you out
> of the box.
>
> The l2tp parameters are described in doc/vpn-config-format.txt, please
> read that documentation. connman-xl2tpd.conf and connman-ppp-option.conf
> are generated on the fly by the l2tp plugin according to the l2tp
> configuration. There are no practical means to modify those config files
> after they have been written by ConnMan.
>
> And do notice that l2tp provides ABSOLUTELY NO security, l2tp and pptp
> must be protected by IPSec in order to be called a VPN. And there is no
> IPSec implemented for connman-vpnd yet.
>
>
Thanks a lot.

OK,  now I understand the connection logic, and I think upstream can add
some rules
to connman/vpn/connman-task.te for allowing l2tp and pptp vpn clients to
access
net.connman.Task dbus interface.

current connman-task.te:

# SElinux policy file for allowing various vpn clients
# to access net.connman.Task dbus interface

module connman-task 1.0;

require {
type openvpn_t;
type openconnect_t;
type vpnc_t;
type initrc_t;
class dbus send_msg;
}

allow openvpn_t initrc_t:dbus send_msg;
allow openconnect_t initrc_t:dbus send_msg;
allow vpnc_t initrc_t:dbus send_msg;
-

Cheers,

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

How to connect the l2tp VPN

2014-01-22 Thread Chengyi Zhao

Hi all,

I would like to connect the l2tp VPN via ConnMan, but  I can't connect the
xl2tp server,
Please share following configure files to me:
connman-xl2tpd.conf
connman-ppp-option.conf

Preferably someone tells me  connection steps, thanks a lot!

All of files come from l2tp.c:
static int run_connect(struct vpn_provider *provider,
struct connman_task *task, const char *if_name,
vpn_provider_connect_cb_t cb, void *user_data,
const char *username, const char *password)
{
char *l2tp_name, *pppd_name;
int l2tp_fd, pppd_fd;
int err;

if (!username || !password) {
DBG("Cannot connect username %s password %p",
username, password);
err = -EINVAL;
goto done;
}

DBG("username %s password %p", username, password);

l2tp_name = g_strdup_printf("/var/run/connman/connman-xl2tpd.conf");

l2tp_fd = open(l2tp_name, O_RDWR|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR);
if (l2tp_fd < 0) {
g_free(l2tp_name);
connman_error("Error writing l2tp config");
err = -EIO;
goto done;
}

pppd_name = g_strdup_printf("/var/run/connman/connman-ppp-option.conf");

pppd_fd = open(pppd_name, O_RDWR|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR);
if (pppd_fd < 0) {
connman_error("Error writing pppd config");
g_free(l2tp_name);
g_free(pppd_name);
close(l2tp_fd);
err = -EIO;
goto done;
}

l2tp_write_config(provider, pppd_name, l2tp_fd);

write_pppd_option(provider, pppd_fd);

connman_task_add_argument(task, "-D", NULL);
connman_task_add_argument(task, "-c", l2tp_name);

g_free(l2tp_name);
g_free(pppd_name);
close(l2tp_fd);
close(pppd_fd);

err = connman_task_run(task, l2tp_died, provider,
NULL, NULL, NULL);
if (err < 0) {
connman_error("l2tp failed to start");
err = -EIO;
goto done;
}

done:
if (cb)
cb(provider, user_data, err);

return err;
}


Cheer,

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

Re: [PATCH v2 05/12] service: Move __connman_service_set_active_session() to session.c

2014-01-13 Thread Chengyi Zhao

Hi,


2014/1/13 Tomasz Bursztyka 

> Hi,
>
>
>  Here session has known which service(session->service) it will connect.
>> I think we can modify "__connman_service_auto_connect()", and add a
>> parameter:
>> __connman_service_auto_connect(struct connman_service *service);
>>
>
> No, first here the session is disconnecting and secondary
> __connman_service_auto_connect() is tightly following the service list
> order and other factors: it's meant to be automatic.
>

Thanks, yes, here session is disconnecting.

In fact, my meaning, when session module call the method
__connman_service_auto_connect，
session knows which service it will connect or disconnect, if ConnMan add a
parameter
"struct connman_service *service"  to __connman_service_auto_connect,
and then ConnMan don't need to lookup the service from service_list again.

I think it is possible to optimize the algorithm, kindly give me your
advice, please.

Example:
void __connman_service_auto_connect(*struct connman_service *service*)
{
DBG("");

if (autoconnect_timeout != 0)
return;

autoconnect_timeout = g_timeout_add_seconds(0, run_auto_connect,
*service*);
}

static gboolean run_auto_connect(*gpointer data*)
{
bool autoconnecting = false;
GList *preferred_tech;

autoconnect_timeout = 0;

DBG("");


*struct connman_service *service = data;*



*if (service) {..}*

preferred_tech = preferred_tech_list_get();
if (preferred_tech) {
autoconnecting = auto_connect_service(preferred_tech, true);
g_list_free(preferred_tech);
}

if (!autoconnecting || __connman_session_running())
auto_connect_service(service_list, false);

if (connman_setting_get_bool("SessionAutoConnectMode"))
auto_disconnect_service();

return FALSE;
}


Thanks a lot.
Chengyi

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

Re: [PATCH v2 00/12] Reimplementation of session selection implementation

2014-01-12 Thread Chengyi Zhao

Hi Daniel,

Please help.

Per session iptables rules in the file "session-overview.txt":
iptables -t mangle -A OUTPUT -m owner [--uid-owner|--gid-owner] $OWNER \
  -j MARK --set-mark $MARK

For example:
iptables -t mangle -A OUTPUT -m owner 1.1 \
  -j MARK --set-mark 258

A APP creates a session, and uses the above rule to route the network.

In this APP, if I create a socket to access the internet, I don't
understand
how kernel knows this socket has created by user 1.1 , and can access the
internet.


Thanks a lot.

Chengyi



2013/12/16 Daniel Wagner 

> Hi,
>
> On 12/13/2013 09:34 AM, Daniel Wagner wrote:
> > From: Daniel Wagner 
> >
> > Hi,
> >
> > v2:
> >   - Rebases to current head
> >   - Fixed disconnect services when last session disconnects().
> > This is done by calling __connman_session_auto_connect().
> > v1:
> >   - Reworked according Patrik's feedback
> > Moved all session related code to session.c
> > v0:
> >   - Initial version
>
> As usual I have updated now the github tree with these patches. For
> additional fun, there are 4 patches on top which gives you the
> named service and filter out feature.
>
> https://github.com/bmwcarit/connman/tree/policy-services-v7
>
> cheers,
> daniel
>
> ___
> connman mailing list
> connman@connman.net
> https://lists.connman.net/mailman/listinfo/connman
>
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH v2 05/12] service: Move __connman_service_set_active_session() to session.c

2014-01-11 Thread Chengyi Zhao

Hi,


2013/12/13 Daniel Wagner 

> From: Daniel Wagner 
>
> Since session.c maintains a map between Services and Sessions
> there is little point in having service.c. doing the same
> thing. The auto connect algorithm is just interested if
> there is a session active and if a given Service type
> matches a Session configuration.
>
> Therefore let's add two functions for service.c which allows
> service.c to ask session.c if there is any session and if
> there is a session which is active for given service.
> ---
>  src/connman.h |   4 ++-
>  src/service.c |  58 
>  src/session.c | 104
> +-
>  3 files changed, 92 insertions(+), 74 deletions(-)
>
>
> @@ -1053,11 +1093,12 @@ static void trigger_disconnect(struct
> connman_session *session)
> if (!info->connect)
> return;
>
> -   __connman_service_set_active_session(false,
> -   info->config.allowed_bearers);
> +   session_set_active(session, false);
>
> info->connect = false;
> info->state = CONNMAN_SESSION_STATE_DISCONNECTED;
> +
> +   __connman_service_auto_connect();
>

Here session has known which service(session->service) it will connect.
I think we can modify "__connman_service_auto_connect()", and add a
parameter:
__connman_service_auto_connect(struct connman_service *service);


Cheers,
Chengyi


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

Re: [PATCH] service: Using the user passphrase when connecting the WEP AP

2014-01-07 Thread Chengyi Zhao

Hi Patrik,


2014/1/7 Patrik Flykt 

>
> Hi,
>
> On Mon, 2014-01-06 at 16:06 +0800, Chengyi Zhao wrote:
>
> > Yes, user shouldn't connect a WEP encrypted WiFi network, and this is
> > a ConnMan's design practice, it is very good, but the downstream
> > product need to support the user case  which user connects a WEP
> > encrypted AP.
> >
> > So I will modify this patch, add a new flag to request the WEP
> > passphrase, and only merge it to the downstream product.
>
> I don't see how a flag would help you with anything here. Please do not
> add such unreviewed code to any downstream product, I have severe doubts
> of it working in the first place
>
> AFAIK the only way to detect an invalid WEP key is the following:
>
> >> The approximately only way of detecting an invalid WEP key is to
> >> notice that traffic for this SSID cannot be decrypted. If this
> >> persists for some time, it is very likely that the WEP passphrase is
> >> incorrect.
>
> Please have a look at the problem from that end first,


Thanks, I agree with you.


> or change the UI
> to always remove the WEP network instead of disconnecting it when
> "Disconnect" functionality is requested from the UI by the user.
>

I don't think UI designers will agree with this point.

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

Re: [PATCH] service: Using the user passphrase when connecting the WEP AP

2014-01-06 Thread Chengyi Zhao

Hi Patrik,

2014/1/3 Patrik Flykt 

>
> Hi,
>
> On Thu, 2014-01-02 at 15:31 +0800, Chengyi Zhao wrote:
> > From: Chengyi Zhao 
> >
> > The WEP mode is specified, and has not 4way-handshake,
> > so wpa_supplicant does not provide any "invalid key message".
>
> The "missing" invalid key error for WEP has nothing to do with WEP not
> implementing 4 way handshake. WEP protocol is specified such that there
> is no indication of a wrong key.
>
> The approximately only way of detecting an invalid WEP key is to notice
> that traffic for this SSID cannot be decrypted. If this persists for
> some time, it is very likely that the WEP passphrase is incorrect.
>
> > For using the user passphrase, when user connectes the WEP mode AP
> > ConnMan need to requst the passphrase from the Agent.
> >
> > And this commit can fix the following issue:
> > Unable to connect with the WEP mode AP again with correct passphrase
> > if connecting the AP with wrong passphrase before.
> > ---
> >  src/service.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/service.c b/src/service.c
> > index 33cce14..c0ea7c5 100644
> > --- a/src/service.c
> > +++ b/src/service.c
> > @@ -5120,6 +5120,7 @@ static void request_input_cb(struct
> connman_service *service,
> >   /* We forget any previous error. */
> >   set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
> >
> > + service->userconnect = FALSE;
>
> Userconnect set to false simply means ConnMan is autoconnecting by
> itself and no input is ever asked from an Agent. Should some input be
> needed with userconnect set to false, the service is set into an
> appropriate error state instead.
>
> So this change nukes our only knowledge of the connection being
> requested by an external entity, i.e. a user.
>

Thanks, I agree with you.


>
> >   __connman_service_connect(service);
> >
> >   } else if (err == -ENOKEY) {
> > @@ -5923,7 +5924,11 @@ int __connman_service_connect(struct
> connman_service *service)
> >   if (!is_ipconfig_usable(service))
> >   return -ENOLINK;
> >
> > - err = service_connect(service);
> > + if (service->userconnect &&
> > + service->security == CONNMAN_SERVICE_SECURITY_WEP)
> {
> > + err = -ENOKEY;
>
> So if a user connects the service, the intention is suddenly to always
> (re-)ask for the WEP passphrase?
>

Maybe the saved WEP passphrase before that is wrong ,
so user connection when calling the function "connect_service" must
(re-)ask for the WEP passhprase.

>
> > + } else
> > + err = service_connect(service);
> >   }
> >
> >   if (err >= 0) {
>
> Combined with the change above, err = service_connect() is run as
> before, but no Agent will ever be asked for any passphrases. I don't
> think this was intended.
>
> Another easy solution could be that the UI should just removes a WEP
> encrypted WiFi network instead of disconnecting it if the user tries to
> do so manually.
>
> Yes, user shouldn't connect a WEP encrypted WiFi network, and this is a
ConnMan's design practice,
it is very good, but the downstream product need to support the user case
which user connects a WEP encrypted AP.

So I will modify this patch, add a new flag to request the WEP passphrase,
and only merge it to the downstream product.

Thanks a lot.

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

[PATCH] service: Using the user passphrase when connecting the WEP AP

2014-01-01 Thread Chengyi Zhao

From: Chengyi Zhao 

The WEP mode is specified, and has not 4way-handshake,
so wpa_supplicant does not provide any "invalid key message".

For using the user passphrase, when user connectes the WEP mode AP
ConnMan need to requst the passphrase from the Agent.

And this commit can fix the following issue:
Unable to connect with the WEP mode AP again with correct passphrase
if connecting the AP with wrong passphrase before.
---
 src/service.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/service.c b/src/service.c
index 33cce14..c0ea7c5 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5120,6 +5120,7 @@ static void request_input_cb(struct connman_service 
*service,
/* We forget any previous error. */
set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
 
+   service->userconnect = FALSE;
__connman_service_connect(service);
 
} else if (err == -ENOKEY) {
@@ -5923,7 +5924,11 @@ int __connman_service_connect(struct connman_service 
*service)
if (!is_ipconfig_usable(service))
return -ENOLINK;
 
-   err = service_connect(service);
+   if (service->userconnect &&
+   service->security == CONNMAN_SERVICE_SECURITY_WEP) {
+   err = -ENOKEY;
+   } else
+   err = service_connect(service);
}
 
if (err >= 0) {
-- 
1.8.1.2

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

[PATCH] Using the user passphrase when connecting the WEP AP

2014-01-01 Thread Chengyi Zhao

From: Chengyi Zhao 

The WEP mode is specified, and has not 4way-handshake,
so wpa_supplicant does not provide any "invalid key message".

For using the user passphrase, when user connectes the WEP mode AP
ConnMan need to requst the passphrase from the Agent.

And this commit can fix the following issue:
Unable to connect with the WEP mode AP again with correct passphrase
if connecting the AP with wrong passphrase before.
---
 src/service.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/service.c b/src/service.c
index 33cce14..c0ea7c5 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5120,6 +5120,7 @@ static void request_input_cb(struct connman_service 
*service,
/* We forget any previous error. */
set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
 
+   service->userconnect = FALSE;
__connman_service_connect(service);
 
} else if (err == -ENOKEY) {
@@ -5923,7 +5924,11 @@ int __connman_service_connect(struct connman_service 
*service)
if (!is_ipconfig_usable(service))
return -ENOLINK;
 
-   err = service_connect(service);
+   if (service->userconnect &&
+   service->security == CONNMAN_SERVICE_SECURITY_WEP) {
+   err = -ENOKEY;
+   } else
+   err = service_connect(service);
}
 
if (err >= 0) {
-- 
1.8.1.2

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

Re: [PATCH] wifi: Fix "Unable to connect with the WEP mode AP again"

2013-12-22 Thread Chengyi Zhao

Hi,


2013/12/20 Patrik Flykt 

>
> Hi,
>
> On Fri, 2013-12-20 at 17:41 +0800, Chengyi Zhao wrote:
>
> > @@ -1425,6 +1426,21 @@ static int network_disconnect(struct
> connman_network *network)
> >   if (!wifi || !wifi->interface)
> >   return -ENODEV;
> >
> > + if (connman_network_get_associating(network) == TRUE)
>
> As Tomasz commented, network_disconnect() is called only when the user
> manually disconnects from the network. So the association check works
> only when the user gets tired of waiting for the network to connect, it
> has no relevance for any other use case.
>

> > - if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY)
> > + if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY ||
> > + (service->favorite == FALSE &&
> > + service->error == CONNMAN_SERVICE_ERROR_CONNECT_FAILED))
> >   __connman_service_set_passphrase(service, NULL);
>
> This does not work as expected. If a service error is
> CONNMAN_SERVICE_ERROR_CONNECT_FAILED, it may be caused by a too long
> distance to the AP. If the device is close enough, it *will* succeed in
> connecting with an invalid passphrase, wait for an IP address and claim
> it's connected successfully since WEP does not report authentication
> errors by design. Once configured with an IPv4 address, static or link
> local in this particualar case, favorite is set for the service and this
> test will stop working. In general it's not a good idea to blindly wipe
> out passphrases as WPA will know if that was the problem.
>
> I don't remember how fast an link-local IPv4 address gets generated, but
> I'd suspect it is, or, in the worst case for this patch, will be fixed
> to happen too quickly for the patch to make any difference.
>
> No, I'm not applying this patch upstream.
>


network_disconnect is called in case not only the user disconnects
explicitly ,
but also connect_timeout invokes explicitly.

Sure, perhaps you are right. but how to better fix the following issue:

Unable to connect with the WEP mode AP again with correct passphrase
if connecting the AP with wrong passphrase before.


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

[PATCH] wifi: Fix "Unable to connect with the WEP mode AP again"

2013-12-20 Thread Chengyi Zhao

From: Jaehyun Kim 

Unable to connect with the WEP mode AP again with correct passphrase
if connecting the AP with wrong passphrase before.

Because the WEP has not 4way-handshake, ConnMan can't receive
the error message of the invalid key, and can't set
the passphrase to NULL when connection failed with wrong passphrase.
---
 plugins/wifi.c | 16 
 src/service.c  |  4 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 533d6df..58bcff2 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1416,6 +1416,7 @@ static void disconnect_callback(int result, 
GSupplicantInterface *interface,
 static int network_disconnect(struct connman_network *network)
 {
struct connman_device *device = connman_network_get_device(network);
+   struct connman_service *service;
struct wifi_data *wifi;
int err;
 
@@ -1425,6 +1426,21 @@ static int network_disconnect(struct connman_network 
*network)
if (!wifi || !wifi->interface)
return -ENODEV;
 
+   if (connman_network_get_associating(network) == TRUE)
+   connman_network_set_error(network,
+   CONNMAN_NETWORK_ERROR_ASSOCIATE_FAIL);
+   else {
+   service = connman_service_lookup_from_network(network);
+
+   if (service != NULL &&
+   (__connman_service_is_connected_state(service,
+   CONNMAN_IPCONFIG_TYPE_IPV4) == FALSE &&
+   __connman_service_is_connected_state(service,
+   CONNMAN_IPCONFIG_TYPE_IPV6) == FALSE) &&
+   (connman_service_get_favorite(service) == FALSE))
+   __connman_service_set_passphrase(service, NULL);
+   }
+
connman_network_set_associating(network, false);
 
if (wifi->disconnecting)
diff --git a/src/service.c b/src/service.c
index 33cce14..6583dbf 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5424,7 +5424,9 @@ int __connman_service_indicate_error(struct 
connman_service *service,
 
set_error(service, error);
 
-   if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY)
+   if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY ||
+   (service->favorite == FALSE &&
+   service->error == CONNMAN_SERVICE_ERROR_CONNECT_FAILED))
__connman_service_set_passphrase(service, NULL);
 
/*
-- 
1.8.1.2

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

[PATCH] wifi: Fix "Unable to connect with the WEP mode AP again"

2013-12-20 Thread Chengyi Zhao

From: Jaehyun Kim 

Unable to connect with the WEP mode AP again with correct passphrase
if connecting the AP with wrong passphrase before.

Because the WEP has not 4way-handshake, ConnMan can't receive
the error message of the invalid key, and can't set
the passphrase to NULL when connection failed with wrong passphrase.
---
 plugins/wifi.c | 16 
 src/service.c  |  4 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 533d6df..58bcff2 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1416,6 +1416,7 @@ static void disconnect_callback(int result, 
GSupplicantInterface *interface,
 static int network_disconnect(struct connman_network *network)
 {
struct connman_device *device = connman_network_get_device(network);
+   struct connman_service *service;
struct wifi_data *wifi;
int err;
 
@@ -1425,6 +1426,21 @@ static int network_disconnect(struct connman_network 
*network)
if (!wifi || !wifi->interface)
return -ENODEV;
 
+   if (connman_network_get_associating(network) == TRUE)
+   connman_network_set_error(network,
+   CONNMAN_NETWORK_ERROR_ASSOCIATE_FAIL);
+   else {
+   service = connman_service_lookup_from_network(network);
+
+   if (service != NULL &&
+   (__connman_service_is_connected_state(service,
+   CONNMAN_IPCONFIG_TYPE_IPV4) == FALSE &&
+   __connman_service_is_connected_state(service,
+   CONNMAN_IPCONFIG_TYPE_IPV6) == FALSE) &&
+   (connman_service_get_favorite(service) == FALSE))
+   __connman_service_set_passphrase(service, NULL);
+   }
+
connman_network_set_associating(network, false);
 
if (wifi->disconnecting)
diff --git a/src/service.c b/src/service.c
index 33cce14..6583dbf 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5424,7 +5424,9 @@ int __connman_service_indicate_error(struct 
connman_service *service,
 
set_error(service, error);
 
-   if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY)
+   if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY ||
+   (service->favorite == FALSE &&
+   service->error == CONNMAN_SERVICE_ERROR_CONNECT_FAILED))
__connman_service_set_passphrase(service, NULL);
 
/*
-- 
1.8.1.2

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

Re: [PATCH v1 09/12] service: Add auto disconnect support

2013-11-12 Thread Chengyi Zhao

Hi Dianel,

Thanks for your reply.


2013/11/11 Daniel Wagner 

> On 11/10/2013 10:47 AM, Chengyi Zhao wrote:
>
>> Hi Daniel,
>>
>>
>> 2013/11/8 Daniel Wagner 
>>
>>  From: Daniel Wagner 
>>>
>>> When SessionAutoConnectMode is enabled we should also make sure
>>> we disconnect unused Services. Unused means there is no
>>> Session is using a Service (__connman_session_in_use()) and
>>> asking for a connection (__connman_session_wants_connection())
>>>
>>>
>> IMHO, if SessionAutoConnectMode is enabled, when service is created
>> session
>> should  be created,
>>
>
> SessionAutoConnectMode is a configuration flag which doesn't change during
> runtime. It changes the way AutoConnect is interpreted. I don't follow
> you here: why should a new Service be created when a Session should also
> be created? Could you please elaborate?


By default, I think the application does not need to create session, so
connman should automatically manager
the session.
In other words, even if the application does not use a session, also
able to use
the default network policy.



>
>  and when service is connected session should be connected,
>>
>
> Yes, that is what is happening now...
>
>
>  of course, and
>> when service is disconnected
>> session should be disconnected.
>>
>
> and this as well. The Service.Connect()/Disconnect() overrule all
> Session.Connect()/Disconnect() actions. What SessionAutoConnectMode
> changes is when the user didn't say Service.Connect() or Disconnect()
> then ConnMan will not connect to any Service unless there is
> a Session asking for a connection -> no session == no connection.
> Currently ConnMan will still try to stay connected due AutoConnect set
> to true.
>  Hope that helps,
>
>
Thanks a lot,  very helpful to me.

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

Re: [PATCH v1 09/12] service: Add auto disconnect support

2013-11-10 Thread Chengyi Zhao

Hi Daniel,


2013/11/8 Daniel Wagner 

> From: Daniel Wagner 
>
> When SessionAutoConnectMode is enabled we should also make sure
> we disconnect unused Services. Unused means there is no
> Session is using a Service (__connman_session_in_use()) and
> asking for a connection (__connman_session_wants_connection())
>

IMHO, if SessionAutoConnectMode is enabled, when service is created session
should  be created,
and when service is connected session should be connected, of course, and
when service is disconnected
session should be disconnected.


> Note if the user did a Service.Connect() (service->userconnect)
> we won't disconnect the Service.
>
> The algorithm could potentially be merged into auto_connect_service()
> but this function is already complex enough let's have a
> auto_disconnect_service() which runs after auto_connect_service(). The
> upside is that we don't change the current play with auto connect
> as it seems to work correctly.
> ---
>  src/connman.h |  2 ++
>  src/service.c | 38 ++
>  src/session.c | 40 
>  3 files changed, 80 insertions(+)
>
>
Cheers,

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

Re: Iptable rules and MARK values for sessions

2013-11-06 Thread Chengyi Zhao

Hi Dianel,

2013/11/6 Daniel Wagner 

> Hi Glenn,
>
>
> On 11/04/2013 08:37 PM, Glenn Schmottlach wrote:
>
>> I have a proposal which I hope the Connman developers will consider.
>>
>
> Sure :)
>
>
>  As I understand it, Connman sessions are tracked, in part, by marking
>> packets associated with the session's UID, GID, or SELinux context
>> information. This is translated into iptable rules to which "mark" the
>> connections as described in session-overview.txt.
>>
>> Per session iptables rules:
>>
>> iptables -t mangle -A OUTPUT -m owner [--uid-owner|--gid-owner] $OWNER \
>>   -j MARK --set-mark $MARK
>>
>> iptables -t filter -A INPUT -m mark --mark $MARK \
>> -m nfacct --nfacct-name session-input-$MARK
>> iptables -t filter -A OUTPUT -m mark --mark $MARK \
>> -m nfacct --nfacct-name session-output-$MARK
>>
>
> BTW, the nfacct is going away. We are going to use NFQUEUE in future.
> Though we still need the MARK unless we can convince the netdev
> guys that the lookup for a policy routing table could be something else
> e.g. cgroup id. For the time being I keep the assumption we need
> the marker.
>

1) I want to know how ConnMan implements the data usage of network for per
APP.
Does ConnMan need to create a session for per APP?

2) the nfacct is going away. why?

3) I don't know why ConnMan should switch to nftables.
Tomasz Bursztyka write a article "ConnMan usage of Netfilter: a close
overview"
(
https://home.regit.org/2013/03/tomasz-bursztyka-connman-usage-of-netfilter-a-close-overview/
).

Reference:
-
Switching to nftables

Application connectivity is a more advanced part involving Netfilter as it
makes a use of statistics and differenciated routing. For example, in a
car, service data must be sent to manufacturer operator and not on the
owner network.

To do so a session system has been implemented. Application can be modified
to open a session to ConnMan. This allow to define a per-session policy for
routing and accounting.

ConnMan team wanted to use a C API to do rules modification but this was
difficult with iptables and xtables. This is not an official API so it is
subject to bugs and change.

ConnMan team has then switch to nftables and is currently working on
stabilizing nftables to ensure the acceptation of the project and of the
maintainability of their solution in the long time. This work is not yet
upstream but there is good chance it will be accepted.

Cheers,

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

Re: [PATCH 0/5] Use interface index instead of name

2013-10-23 Thread Chengyi Zhao

2013/10/21 Jukka Rissanen 

> Hi,
>
> this patchset tries to minimize the risk of race conditions
> when interface name is changed. This issue was already tackled
> by commit 98919ac6cbc7535309d308363a249a0cdfe0af22 but if the
> rtnl messages come in wrong order, then it is possible that we
> miss the interface name change.
>
> In order to avoid this race, we only use the interface index
> which cannot change and only convert to interface name when
> needed.
>
>
> Cheers,
> Jukka
>
>
> Jukka Rissanen (5):
>   vpn: Removed unused interface name variable
>   technology: Do not use interface name when removing interface
>   technology: Do not use interface name when adding interface
>   rtnl: Do not remember interface name
>   ipconfig: Do not remember interface name
>
>  src/connman.h|  21 +++---
>  src/ipconfig.c   | 193
> +++
>  src/ipv6pd.c |   9 +--
>  src/rtnl.c   |  28 
>  src/service.c|  35 ++
>  src/technology.c |  14 +++-
>  vpn/vpn-rtnl.c   |   3 -
>  7 files changed, 170 insertions(+), 133 deletions(-)
>

Great! I really hope Upstream will apply this patchset.

Cheers,

Chengyi

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

Re: [PATCH 4/5] rtnl: Do not remember interface name

2013-10-21 Thread Chengyi Zhao

Hi Jukka,


2013/10/21 Jukka Rissanen 

> Use always the interface index and only when interface name
> is needed, then fetch the name. This minimizes races when
> interface name changes because of udev rules.
> ---
>  src/rtnl.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/src/rtnl.c b/src/rtnl.c
> index e2e16d0..f8f1429 100644
> --- a/src/rtnl.c
> +++ b/src/rtnl.c
> @@ -65,7 +65,6 @@ static guint update_timeout = 0;
>
>  struct interface_data {
> int index;
> -   char *name;
> char *ident;
> enum connman_service_type service_type;
> enum connman_device_type device_type;
> @@ -81,7 +80,6 @@ static void free_interface(gpointer data)
> interface->index, interface->ident);
>
> g_free(interface->ident);
> -   g_free(interface->name);
> g_free(interface);
>  }
>
> @@ -120,11 +118,13 @@ static bool wext_interface(char *ifname)
>
>  static void read_uevent(struct interface_data *interface)
>  {
> -   char *filename, line[128];
> +   char *filename, *name, line[128];
> bool found_devtype;
> FILE *f;
>
> -   if (ether_blacklisted(interface->name)) {
> +   name = connman_inet_ifname(interface->index);
> +
> +   if (ether_blacklisted(name)) {
> interface->service_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
> interface->device_type = CONNMAN_DEVICE_TYPE_UNKNOWN;
> } else {
> @@ -132,15 +132,14 @@ static void read_uevent(struct interface_data
> *interface)
> interface->device_type = CONNMAN_DEVICE_TYPE_ETHERNET;
> }
>
> -   filename = g_strdup_printf("/sys/class/net/%s/uevent",
> -   interface->name);
> +   filename = g_strdup_printf("/sys/class/net/%s/uevent", name);
>
> f = fopen(filename, "re");
>
> g_free(filename);
>
> if (!f)
> -   return;
> +   goto out;
>

systemd-udevd concomitantly loads or controls modules, so maybe interface
name will be renamed before excusing the code "filename =
g_strdup_printf("/sys/class/net/%s/uevent", name);",
so I think we could add the following code:

-if (!f)
+if (!f) {
+interface->service_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
+interface->device_type = CONNMAN_DEVICE_TYPE_UNKNOWN;
- return;
+ goto out;
+}

Because the code logic tells us the interface default service_type
is CONNMAN_SERVICE_TYPE_ETHERNET and device_type is
CONNMAN_DEVICE_TYPE_ETHERNET, when opening the file failed, all of types
will be set to
default type, this is not correct, maybe wlan0 interface will be treated as
ethernet type.

Please refer to the following log of starting connman, wlan0 interface is
treated as ethernet type, not wifi type:

connmand[175]: src/rtnl.c:rtnl_message() NEWLINK len 1072 type 16 flags
0x0002 seq 0 pid 175
connmand[175]: src/ipconfig.c:__connman_ipconfig_newlink() index 3
connmand[175]: wlp2s0 {create}index 3 type 1 
connmand[175]: wlp2s0{update}flags 4098 
connmand[175]: wlan0{newlink} index 3 address 0C:8B:FD:22:B8:7A mtu 1500
connmand[175]: wlan0 {newlink}index 3 operstate 2 
connmand[175]: src/detect.c:detect_newlink() type 1 index 3
connmand[175]: src/device.c:connman_device_create() node 0c8bfd22b87a type 1
connmand[175]: src/device.c:connman_device_create() device 0x9223388
connmand[175]: src/device.c:connman_device_set_string() device 0x9223388
key Address value 0C:8B:FD:22:B8:7A
connmand[175]: src/device.c:connman_device_register() device 0x9223388 name
Ethernet
connmand[175]: src/device.c:connman_device_register() driver 0x80f48e0 name
ethernet
connmand[175]: plugins/ethernet.c:ethernet_probe() device 0x9223388
connmand[175]: src/rtnl.c:connman_rtnl_add_newlink_watch() id 2
connmand[175]: plugins/ethernet.c:ethernet_newlink() index 3 flags 4098
change 0
connmand[175]: src/technology.c:__connman_technology_add_device() device
0x9223388 type Wired
connmand[175]: src/technology.c:technology_get() type 2
connmand[175]: src/technology.c:technology_find() type 2
connmand[175]: src/device.c:__connman_device_enable() device 0x9223388
connmand[175]: plugins/ethernet.c:ethernet_enable() device 0x9223388
connmand[175]: Adding interface wlan0 [ ethernet ]

URL: https://bugs.tizen.org/jira/browse/TIVI-1885.

Cheers,

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

Re: [PATCH 2/2] rtnl: Set the unknow type if the related interface can not be found

2013-10-18 Thread Chengyi Zhao

2013/10/18 Patrik Flykt 

> On Fri, 2013-10-18 at 18:35 +0800, Chengyi Zhao wrote:
> > From: Chengyi Zhao 
> >
> > If system can't find the related network interface
> > in /sys/class/net/,ConnMan will set the unknow type to this interface.
> > ---
> >  src/rtnl.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/rtnl.c b/src/rtnl.c
> > index 6d47822..eda6b25 100644
> > --- a/src/rtnl.c
> > +++ b/src/rtnl.c
> > @@ -139,8 +139,11 @@ static void read_uevent(struct interface_data
> *interface)
> >
> >   g_free(filename);
> >
> > - if (!f)
> > + if (!f) {
> > + interface->service_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
> > + interface->device_type = CONNMAN_DEVICE_TYPE_UNKNOWN;
> >   return;
> > + }
>
> If ethernet has always had an uevent file (above, where 'f' is opened),
> the default non-blacklisted branch where ethernet types were set could
> be moved between 'if (!f) return;' and 'found_devtype = false;'. If
> ethernet has not always had an uevent file, this cannot be done.
>
> What is the bug you are fixing here?
>
> Please  investigate this issue:

TIVI-1885 [3.0] net.connman.Error.NotImplemented when trying to scan
wifi<https://bugs.tizen.org/jira/browse/TIVI-1885>

Cheers,

Chengyi
<https://bugs.tizen.org/jira/browse/TIVI-1885>
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH 1/2] rtnl: Catch network interface name changes

2013-10-18 Thread Chengyi Zhao

2013/10/18 Patrik Flykt 

> On Fri, 2013-10-18 at 18:35 +0800, Chengyi Zhao wrote:
> > From: Chengyi Zhao 
> >
> > Update the network interface name if it is renamed by
> > systemd-udevd or udevd. When system starting,
> > the newlink ifname of ConnMan received from kernel is wlan0,
> > but systemd-udevd renamed network interface wlan0 to other name.
> > ---
> >  src/rtnl.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/rtnl.c b/src/rtnl.c
> > index 0d68337..6d47822 100644
> > --- a/src/rtnl.c
> > +++ b/src/rtnl.c
> > @@ -451,7 +451,7 @@ static void process_newlink(unsigned short type, int
> index, unsigned flags,
> >   if (!interface) {
> >   interface = g_new0(struct interface_data, 1);
> >   interface->index = index;
> > - interface->name = g_strdup(ifname);
> > + interface->name = connman_inet_ifname(index);
> >   interface->ident = g_strdup(ident);
> >
> >   g_hash_table_insert(interface_list,
>
> This case is already fixed with upstream commit
> 98919ac6cbc7535309d308363a249a0cdfe0af22. What ConnMan version is this
> patch intended for?
>

The commit 98919ac6cbc7535309d308363a249a0cdfe0af22 is not same with this.
This patch will fix the issue
TIVI-1885<https://bugs.tizen.org/jira/browse/TIVI-1885>
.

Cheers,

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

[PATCH 1/2] rtnl: Catch network interface name changes

2013-10-18 Thread Chengyi Zhao

From: Chengyi Zhao 

Update the network interface name if it is renamed by
systemd-udevd or udevd. When system starting,
the newlink ifname of ConnMan received from kernel is wlan0,
but systemd-udevd renamed network interface wlan0 to other name.
---
 src/rtnl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rtnl.c b/src/rtnl.c
index 0d68337..6d47822 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -451,7 +451,7 @@ static void process_newlink(unsigned short type, int index, 
unsigned flags,
if (!interface) {
interface = g_new0(struct interface_data, 1);
interface->index = index;
-   interface->name = g_strdup(ifname);
+   interface->name = connman_inet_ifname(index);
interface->ident = g_strdup(ident);
 
g_hash_table_insert(interface_list,
-- 
1.7.9.5

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

[PATCH 2/2] rtnl: Set the unknow type if the related interface can not be found

2013-10-18 Thread Chengyi Zhao

From: Chengyi Zhao 

If system can't find the related network interface
in /sys/class/net/,ConnMan will set the unknow type to this interface.
---
 src/rtnl.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/rtnl.c b/src/rtnl.c
index 6d47822..eda6b25 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -139,8 +139,11 @@ static void read_uevent(struct interface_data *interface)
 
g_free(filename);
 
-   if (!f)
+   if (!f) {
+   interface->service_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
+   interface->device_type = CONNMAN_DEVICE_TYPE_UNKNOWN;
return;
+   }
 
found_devtype = false;
while (fgets(line, sizeof(line), f)) {
-- 
1.7.9.5

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

[PATCH] rtnl: Catch network interface name changes

2013-10-18 Thread Chengyi Zhao

From: Chengyi Zhao 

Update the network interface name if it is renamed by systemd-udevd or udevd.
When system starting, the newlink ifname of ConnMan received from kernel is 
wlan0,
but systemd-udevd renamed network interface wlan0 to other name.
---
 src/rtnl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rtnl.c b/src/rtnl.c
index 0d68337..6d47822 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -451,7 +451,7 @@ static void process_newlink(unsigned short type, int index, 
unsigned flags,
if (!interface) {
interface = g_new0(struct interface_data, 1);
interface->index = index;
-   interface->name = g_strdup(ifname);
+   interface->name = connman_inet_ifname(index);
interface->ident = g_strdup(ident);
 
g_hash_table_insert(interface_list,
-- 
1.7.9.5

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

Re: Could ConnMan provide the new interface for controlling the DHCP

2013-09-17 Thread Chengyi Zhao

Hi Simon,


2013/8/2 Simon Busch 

> On Friday 02 August 2013 12:45:09 Patrik Flykt wrote:
> > On Fri, 2013-08-02 at 17:00 +0800, Chengyi Zhao wrote:
> > > Your meanings are downstream product should use ConnMan WiFi P2P
> > > instead of
> > > the other external WiFi P2P software.
> >
> > Yes. When implemented, ConnMan WiFi P2P support should be used.
> >
> > > But, when will Upstream release ConnMan WiFi P2P.
> >
> > Ah, that's the tricky question :-) Let's see, currently I don't have any
> > good estimates as no code has been written...
>
> I am planing to send another version of my WiFi Direct API proposal over
> the
> weekend so the discussion can continue.
>
> Overall this isn't a simple thing you implement in one or two weeks. A lot
> of
> things needs to be considered especially with the available WiFi drivers
> handling things differently.
>
>
I found a great many wifi chipes use nl802.11 driver.
I suggest you directly use the wpa_supplicant to operate the driver
interface.

I am very honored to have read your document 'WiFi direct API proposal v2'.
In general, I agree with your design.
Very much looking forward to see the p2p code in connman.

Cheers,

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

Re: Could ConnMan provide the new interface for controlling the DHCP

2013-09-16 Thread Chengyi Zhao

2013/9/16 Patrik Flykt 

> On Sat, 2013-09-14 at 14:35 +0800, Chengyi Zhao wrote:
> > I have a requirement that the other third-party program need to use
> > DHCP
> > service, how can I do it.
>
> What other third party program? DHCP server or client? There are no
> plans to make the DHCP server or client code detachable from core
> ConnMan.
>

Thanks Patrik. I think I should change my idea.

Cheers,

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

Re: Could ConnMan provide the new interface for controlling the DHCP

2013-09-13 Thread Chengyi Zhao

Hi All,

I have a requirement that the other third-party program need to use DHCP
service, how can I do it.

Cheers,

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

Re: [PATCH] Tethering: Add the hidden Access Point

2013-05-22 Thread Chengyi Zhao

Hi Marcel,

2013/5/22 Marcel Holtmann :
> Hi Chengyi,
>
 I'm not sure we want the capability of hiding the SSID when tethering,
 let's figure out that one as well.
>>>
>>> I do not think this is a good idea in the first place. Hidden SSID is the
>>> most stupid concept invented. It does not provide any extra security.
>>> Especially not if you have actual clients connected. The SSID will be
>>> resolved eventually if you do an air trace. And if you do not connect to,
>>> then instead of hiding it, rather disable it and stop wasting power.
>>>
>>> There is a reason why we are forcing WPA2 for Tethering access points and
>>> do not allow insecure Tethering. With that in mind the hidden SSID is not
>>> useful whatsoever either.
>>>
>>> Keep also in mind that features like WPS, P2P and even Bluetooth
>>> High-Speed are forcing the SSID to be broadcast. So hidden WiFi is so
>>> 90ties ;)
>>>
>>>
>> I agree with you that strict security control is very important,
>> but this specific request is from Tizen mobile develop group,
>> and the other also includes open Wi-Fi Access points.
>
> neither Android nor iOS supports hidden AP for Tethering. So what is your 
> point here?

Android(Samsung release) supports hidden AP for Tethering.

>
>> The hostap or wpa_spplicant supports almost all of the security features,
>> so I think that security can be selected by the user or APP developer,
>> and we can provide instructions and recommendations in the interface file.
>
> This is not a valid argument. The Linux kernel still supports DECnet network 
> protocols, but that is pretty much a dead technology. No sane distribution 
> would try to enable support for it.
>
> The takeaway from this is that enabling every single possible low-level 
> option all the way to the user is not useful. Especially if this leads to 
> false sense of security. You would have to spent more time to explain to the 
> user that hidden does not mean actually secure. That makes the UI design and 
> interaction design more complicated. And still most normal users will not get 
> it. So it is better to not just do it at all if there is not a single benefit.
>
> And hidden WiFi falls exactly into this category. Upstream can not support 
> such an option.
>

Thank you very much for your analysis.
I have gradually known the specified standard of ConnMan security, and
I think this is very valuable thinking or opinion.

So I don't plan to submit this patch to Upstream, and I will only
submit it to downstream product.

Best Regards

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

Re: [PATCH] Tethering: Add the hidden Access Point

2013-05-21 Thread Chengyi Zhao

Hi Marcel,

Hi Patrik,
>
> > I'm not sure we want the capability of hiding the SSID when tethering,
> > let's figure out that one as well.
>
> I do not think this is a good idea in the first place. Hidden SSID is the
> most stupid concept invented. It does not provide any extra security.
> Especially not if you have actual clients connected. The SSID will be
> resolved eventually if you do an air trace. And if you do not connect to,
> then instead of hiding it, rather disable it and stop wasting power.
>
> There is a reason why we are forcing WPA2 for Tethering access points and
> do not allow insecure Tethering. With that in mind the hidden SSID is not
> useful whatsoever either.
>
> Keep also in mind that features like WPS, P2P and even Bluetooth
> High-Speed are forcing the SSID to be broadcast. So hidden WiFi is so
> 90ties ;)
>
>
I agree with you that strict security control is very important,
but this specific request is from Tizen mobile develop group,
and the other also includes open Wi-Fi Access points.

The hostap or wpa_spplicant supports almost all of the security features,
so I think that security can be selected by the user or APP developer,
and we can provide instructions and recommendations in the interface file.

Best Regards,

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

Re: [PATCH] Tethering: Add the hidden Access Point

2013-05-21 Thread Chengyi Zhao

git://w1.fi/srv/git/hostap.git

commit e62f4ed0df72987f874b9bc5c9fa8bec938133ac
Author: Vivek Natarajan 
Date:   Mon Feb 27 16:28:45 2012 +0200

Add support for hidden SSID in wpa_supplicant AP mode

This also disables WPS support if hidden SSID is enabled in AP mode.

Signed-off-by: Vivek Natarajan 
Signed-hostap: Jouni Malinen 

diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c
index 52f421a..48a6169 100644
--- a/wpa_supplicant/ap.c
+++ b/wpa_supplicant/ap.c
@@ -145,6 +145,8 @@ static int wpa_supplicant_conf_ap(struct wpa_supplicant
*wpa_s,
bss->ssid.ssid_len = ssid->ssid_len;
bss->ssid.ssid_set = 1;

+   bss->ignore_broadcast_ssid = ssid->ignore_broadcast_ssid;
+
if (ssid->auth_alg)
bss->auth_algs = ssid->auth_alg;

@@ -238,7 +240,10 @@ static int wpa_supplicant_conf_ap(struct
wpa_supplicant *wpa_s,
  * configuration */
 #endif /* CONFIG_WPS2 */
bss->eap_server = 1;
-   bss->wps_state = 2;
+
+   if (!ssid->ignore_broadcast_ssid)
+   bss->wps_state = 2;
+
bss->ap_setup_locked = 2;
if (wpa_s->conf->config_methods)
bss->config_methods =
os_strdup(wpa_s->conf->config_methods);
diff --git a/wpa_supplicant/config.c b/wpa_supplicant/config.c
index 9fd2a70..0aae8af 100644
--- a/wpa_supplicant/config.c
+++ b/wpa_supplicant/config.c
@@ -1589,6 +1589,7 @@ static const struct parse_data ssid_fields[] = {
{ INT_RANGE(frequency, 0, 1) },
{ INT(wpa_ptk_rekey) },
{ STR(bgscan) },
+   { INT_RANGE(ignore_broadcast_ssid, 0, 2) },
 #ifdef CONFIG_P2P
{ FUNC(p2p_client_list) },
 #endif /* CONFIG_P2P */
diff --git a/wpa_supplicant/config_ssid.h b/wpa_supplicant/config_ssid.h
index 2605ae8..f2bb597 100644
--- a/wpa_supplicant/config_ssid.h
+++ b/wpa_supplicant/config_ssid.h
@@ -377,6 +377,20 @@ struct wpa_ssid {
char *bgscan;


Best Regards,

Chengyi


2013/5/21 Jukka Rissanen 

> Hi,
>
>
> On 21.05.2013 13:39, Chengyi Zhao wrote:
>
>> From: Chengyi Zhao 
>>
>> Sometimes users need create the hidden Wi-Fi Access Point.
>>
>> Because wpa_supplicant 2.0 has already added this hidden DBus interface
>> (the code "int ignore_broadcast_ssid;" of the file config_ssid.h, etc),
>> it is recommended to use wpa_supplicant 2.0 or later.
>>
>> Signed-off-by: Chengyi Zhao 
>> ---
>>   doc/technology-api.txt |5 +
>>   gsupplicant/gsupplicant.h  |7 +++
>>   gsupplicant/supplicant.c   |4 
>>   include/technology.h   |3 ++-
>>   plugins/bluetooth.c|3 ++-
>>   plugins/bluetooth_legacy.c |3 ++-
>>   plugins/ethernet.c |6 --
>>   plugins/wifi.c |   14 +++---
>>   src/technology.c   |   22 +-
>>   9 files changed, 58 insertions(+), 9 deletions(-)
>>
>>
>
>  --- a/gsupplicant/supplicant.c
>> +++ b/gsupplicant/supplicant.c
>> @@ -3460,6 +3460,10 @@ static void 
>> interface_add_network_params(**DBusMessageIter
>> *iter, void *user_data)
>> DBUS_TYPE_BYTE, &ssid->ssid,
>> ssid->ssid_len);
>>
>> +   supplicant_dbus_dict_append_**basic(&dict,
>> "ignore_broadcast_ssid",
>> +   DBUS_TYPE_INT32,
>> +   &ssid->ignore_broadcast_ssid);
>> +
>> supplicant_dbus_dict_close(**iter, &dict);
>>   }
>>
>>
> After a quick look into wpa_supplicant sources, I could not find this
> ignore_broadcast_ssid property being handled in the dbus handler code.
> What version of supplicant contains support for this dbus property?
>
>
> Cheers,
> Jukka
>
>
> __**_
> connman mailing list
> connman@connman.net
> https://lists.connman.net/**mailman/listinfo/connman<https://lists.connman.net/mailman/listinfo/connman>
>
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

[PATCH] Tethering: Add the hidden Access Point

2013-05-21 Thread Chengyi Zhao

From: Chengyi Zhao 

Sometimes users need create the hidden Wi-Fi Access Point.

Because wpa_supplicant 2.0 has already added this hidden DBus interface
(the code "int ignore_broadcast_ssid;" of the file config_ssid.h, etc),
it is recommended to use wpa_supplicant 2.0 or later.

Signed-off-by: Chengyi Zhao 
---
 doc/technology-api.txt |5 +
 gsupplicant/gsupplicant.h  |7 +++
 gsupplicant/supplicant.c   |4 
 include/technology.h   |3 ++-
 plugins/bluetooth.c|3 ++-
 plugins/bluetooth_legacy.c |3 ++-
 plugins/ethernet.c |6 --
 plugins/wifi.c |   14 +++---
 src/technology.c   |   22 +-
 9 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/doc/technology-api.txt b/doc/technology-api.txt
index 92886e1..b48f88d 100644
--- a/doc/technology-api.txt
+++ b/doc/technology-api.txt
@@ -94,6 +94,11 @@ Properties   boolean Powered [readwrite]
and is then mapped to the WPA pre-shared key clients
will have to use in order to establish a connection.
 
+   boolean Hidden [readwrite]
+
+   This option allows to enable or disable the support
+   for the hidden Wi-Fi tethering.
+
uint32  IdleTimeout [readwrite] [experimental]
 
If the technology is idle for given period then it
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index da45075..345e0b9 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -113,6 +113,12 @@ typedef enum {
G_SUPPLICANT_WPS_STATE_FAIL,
 } GSupplicantWpsState;
 
+enum GSupplicantAPHiddenSSID {
+   G_SUPPLICANT_AP_NO_SSID_HIDING,
+   G_SUPPLICANT_AP_HIDDEN_SSID_ZERO_LEN,
+   G_SUPPLICANT_AP_HIDDEN_SSID_ZERO_CONTENTS,
+} ;
+
 struct _GSupplicantSSID {
const void *ssid;
unsigned int ssid_len;
@@ -134,6 +140,7 @@ struct _GSupplicantSSID {
dbus_bool_t use_wps;
const char *pin_wps;
const char *bgscan;
+   int ignore_broadcast_ssid;
 };
 
 typedef struct _GSupplicantSSID GSupplicantSSID;
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 30f0660..a305125 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3460,6 +3460,10 @@ static void interface_add_network_params(DBusMessageIter 
*iter, void *user_data)
DBUS_TYPE_BYTE, &ssid->ssid,
ssid->ssid_len);
 
+   supplicant_dbus_dict_append_basic(&dict, "ignore_broadcast_ssid",
+   DBUS_TYPE_INT32,
+   &ssid->ignore_broadcast_ssid);
+
supplicant_dbus_dict_close(iter, &dict);
 }
 
diff --git a/include/technology.h b/include/technology.h
index 9fe994c..8f89f98 100644
--- a/include/technology.h
+++ b/include/technology.h
@@ -59,7 +59,8 @@ struct connman_technology_driver {
int index);
int (*set_tethering) (struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled);
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden);
int (*set_regdom) (struct connman_technology *technology,
const char *alpha2);
 };
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 4aac1e0..4ecbc37 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -826,7 +826,8 @@ static void bluetooth_tech_remove(struct connman_technology 
*technology)
 
 static int bluetooth_tech_set_tethering(struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled)
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden)
 {
GHashTableIter hash_iter;
gpointer key, value;
diff --git a/plugins/bluetooth_legacy.c b/plugins/bluetooth_legacy.c
index 41438f4..57ad7da 100644
--- a/plugins/bluetooth_legacy.c
+++ b/plugins/bluetooth_legacy.c
@@ -1225,7 +1225,8 @@ static void disable_nap(gpointer key, gpointer value, 
gpointer user_data)
 
 static int tech_set_tethering(struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled)
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden)
 {
struct tethering_info info = {
.technology = technology,
diff --git a/plugins/ethernet.

[PATCH] Tethering: Add the hidden Access Point

2013-05-21 Thread Chengyi Zhao

From: Chengyi Zhao 

Sometimes users need create the hidden Wi-Fi Access Point

Signed-off-by: Chengyi Zhao 
---
 doc/technology-api.txt |5 +
 gsupplicant/gsupplicant.h  |7 +++
 gsupplicant/supplicant.c   |4 
 include/technology.h   |3 ++-
 plugins/bluetooth.c|3 ++-
 plugins/bluetooth_legacy.c |3 ++-
 plugins/ethernet.c |6 --
 plugins/wifi.c |   14 +++---
 src/technology.c   |   22 +-
 9 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/doc/technology-api.txt b/doc/technology-api.txt
index 92886e1..b48f88d 100644
--- a/doc/technology-api.txt
+++ b/doc/technology-api.txt
@@ -94,6 +94,11 @@ Properties   boolean Powered [readwrite]
and is then mapped to the WPA pre-shared key clients
will have to use in order to establish a connection.
 
+   boolean Hidden [readwrite]
+
+   This option allows to enable or disable the support
+   for the hidden Wi-Fi tethering.
+
uint32  IdleTimeout [readwrite] [experimental]
 
If the technology is idle for given period then it
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index da45075..e4646ba 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -113,6 +113,12 @@ typedef enum {
G_SUPPLICANT_WPS_STATE_FAIL,
 } GSupplicantWpsState;
 
+enum {
+   G_SUPPLICANT_AP_NO_SSID_HIDING,
+   G_SUPPLICANT_AP_HIDDEN_SSID_ZERO_LEN,
+   G_SUPPLICANT_AP_HIDDEN_SSID_ZERO_CONTENTS,
+} ;
+
 struct _GSupplicantSSID {
const void *ssid;
unsigned int ssid_len;
@@ -134,6 +140,7 @@ struct _GSupplicantSSID {
dbus_bool_t use_wps;
const char *pin_wps;
const char *bgscan;
+   int ignore_broadcast_ssid;
 };
 
 typedef struct _GSupplicantSSID GSupplicantSSID;
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 30f0660..a305125 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3460,6 +3460,10 @@ static void interface_add_network_params(DBusMessageIter 
*iter, void *user_data)
DBUS_TYPE_BYTE, &ssid->ssid,
ssid->ssid_len);
 
+   supplicant_dbus_dict_append_basic(&dict, "ignore_broadcast_ssid",
+   DBUS_TYPE_INT32,
+   &ssid->ignore_broadcast_ssid);
+
supplicant_dbus_dict_close(iter, &dict);
 }
 
diff --git a/include/technology.h b/include/technology.h
index 9fe994c..8f89f98 100644
--- a/include/technology.h
+++ b/include/technology.h
@@ -59,7 +59,8 @@ struct connman_technology_driver {
int index);
int (*set_tethering) (struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled);
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden);
int (*set_regdom) (struct connman_technology *technology,
const char *alpha2);
 };
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 4aac1e0..4ecbc37 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -826,7 +826,8 @@ static void bluetooth_tech_remove(struct connman_technology 
*technology)
 
 static int bluetooth_tech_set_tethering(struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled)
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden)
 {
GHashTableIter hash_iter;
gpointer key, value;
diff --git a/plugins/bluetooth_legacy.c b/plugins/bluetooth_legacy.c
index 41438f4..57ad7da 100644
--- a/plugins/bluetooth_legacy.c
+++ b/plugins/bluetooth_legacy.c
@@ -1225,7 +1225,8 @@ static void disable_nap(gpointer key, gpointer value, 
gpointer user_data)
 
 static int tech_set_tethering(struct connman_technology *technology,
const char *identifier, const char *passphrase,
-   const char *bridge, connman_bool_t enabled)
+   const char *bridge, connman_bool_t enabled,
+   connman_bool_t hidden)
 {
struct tethering_info info = {
.technology = technology,
diff --git a/plugins/ethernet.c b/plugins/ethernet.c
index bafc75d..a9c6910 100644
--- a/plugins/ethernet.c
+++ b/plugins/ethernet.c
@@ -284,7 +284,8 @@ static void disable_tethering(struct connman_technology 
*technology,
 
 static int tech_set_tethering(st

Re: gadget ethernet problem

2013-04-15 Thread Chengyi Zhao

Hi Petr,

I think you can try this patch .

Best Regards,

Chengyi



On Mon, Apr 15, 2013 at 10:20 PM, Petr Masek  wrote:

> Hi Patrik,
> attached you'll find a patch, which changes only plugins/ethernet.c.
>
> Yes, there is really some other (probably small issue), which I also found
> out.
>
> In /vat/lib/connman/settings now appears this:
>
> [global]
> OfflineMode=true
>
> [WiFi]
> Enable=true
>
> [Bluetooth]
> Enable=false
>
> [Gadget]
> Enable=true
>
> [(null)]
> Enable=false
>
> The last section should probably be [Gadget]. So there is really something
> not completely fixed. I'll investigate, but if you have any idea where to
> look, you help will be appreciated.
>
> Our user scenario is following:
> 1. Connect our device to PC
> 2. Let's assume, that there is Windows 7 running. So we provide correct
> inf file for gadget ethernet.
> 3. On the device, we set correct IP, Mask, DNS, Gateway via it's user UI.
> This is where we want Connman to help. So no DHCP is required. Just working
> connman, which allows easy connection between our UI and network interface.
> 4. In Manage network connection on Windows, we can set appropriate IP and
> Mask via setting panel.
> 5. Connection is now estabilished and 3rd party programs, which wants
> communicate with our device can do it just using TPC/IP. No USB driver
> interaction would be required.
> 6. If a remote access is required, user can bridge USB interface and LAN
> interface in Windows ( http://windows.microsoft.com/**
> is-is/windows-vista/create-a-**network-bridge
> ).
>
> Yes, it takes some time to configure this, but it is in order of minutes
> to do that. Do you really think, that this scenario is so exotic? I guess
> that industrial devices are commonly used in this way. We design it this
> way to allow easy creation of 3rd part apps (as everybody can do TCP IP,
> but USB driver interface is much more difficult to write, mainly in
> windows). And it also allows us to use multiple services, which direct USB
> would not allow (SSH, SFTP, HTTP, etc).
>
> Hope I make it clear.
>
>
> thank you and best regards
>
> Petr
>
>
>  On Mon, 2013-04-15 at 15:28 +0200, Petr Masek wrote:
>>
>>> no, this was the first part of problem. This part of patch fixed it:
>>>
>>> +err = connman_device_driver_**register(&dev_gadget_driver);
>>>
>> Ok, this is the thing that probably has changed over the years and is no
>> longer working. It would be nice to have the patch split up so that the
>> fix for technology was in a patch of its own as this is something that
>> needs fixing.
>>
>> I need to think some more about exposing services for the gadget device.
>> First of all they should show up named as 'gadget_*', so something is
>> still not quite right here. There probably are still some more -EINVALs
>> lurking in other places in the code.
>>
>> The question is how you will manage this from the laptop/desktop/USB
>> host side. Normally no machine comes with capabilities for providing
>> DHCP server support and NAT to the outside network. For linux one can
>> always put something together, but I don't think other OSes have a
>> particular good chance of getting this right. I'd guess the current
>> setup probably ended up with link-local IPv4 addresses on the interface?
>> Is it enough connectivity for your use case if ConnMan running on this
>> gadget device would just enable tethering and hand out DHCP addresses to
>> the connected laptop? What use case do you have in mind where the
>> reverse is true with the USB host side on the laptop hands out DHCP
>> addresses to the USB client?
>>
>>
>> Cheers,
>>
>> Patrik
>> __**_
>> connman mailing list
>> connman@connman.net
>> http://lists.connman.net/**listinfo/connman
>>
>
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>


0001-Create-the-technology-for-the-new-interface.patch
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Update the time through the NTP

2013-01-06 Thread Chengyi Zhao

Hi all,

I think ConnMan should control to update the time through the  property
"TimeUpdates" of net.connman.Clock.

If the  property "TimeUpdates" is set to "manual", ConnMan should not
update the time through the NTP,
of course, if the  property "TimeUpdates" is set to "auto", and the other
conditions are ready, ConnMan can update the time from network through the
NTP.

Are you agree with me?
Thanks for your attention.

Best regards,
Chengyi Zhao
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

simple-agent: passphrase contains spaces can not be received correctly

2012-11-06 Thread Chengyi Zhao

Hi All,

 I write about two items in this letter. one is about the error
that the passphrase contains spaces can not be received correctly, a module
is imported to resolve this error. The other is about a new error
discovered during testing simple-agent,luckily, this discovered error is
also kicked.
simple-agent can not receive passwords that contains  spaces, for
example,  the following command:"./simple-agent Identity = ap, passphrase=
12345678 9 " will get errors, because the space between 8 and 9 is
recognized as the dividing sign of two different arguments. To solve this
problem, the getpass module is imported. The getpass module can receive any
character that gotten through the keyboard. The mainly changes are as below:
1. import getpass

2. print "%s Identity= need-Passphrase=yes
WPS=" % (sys.argv[0])

3. if arg.startswith("need-Passphrase="):
passphrase = getpass.getpass('passphrase:')

4. if arg.startswith("need-Password="):
response["Password"] = getpass.getpass('password:')

5.  elif arg.startswith("need-Passphrase="):
object.passphrase = getpass.getpass('passphrase:')

6.  elif arg.startswith("need-Password="):
object.password = getpass.getpass('password:')

so far,this problem is kicked, however, another error occurs. when running
the command "./simple-agent Identity=ap", the wifi cannot be connected
successfully. when running the command "./test-connman connect **" to
connect wifi, repeated and continuous error information :
   RequestInput (/net/connman/service
/wifi_00dbdf140abe_6170_managed_psk,dbus.Dictionary({dbus.String(u'Passphrase'):
dbus.Dictionary({dbus.String(u'Requirement'): dbus.String(u'mandatory',
variant_level=1), dbus.String(u'Type'): dbus.String(u'psk',
variant_level=1)}, signature=dbus.Signature('sv'), variant_level=1)},
signature=dbus.Signature('sv')))
^CTraceback (most recent call last)
 occur in the terminal where the simple-agent script runs. That is to say
,at the beginning if only the argument of "Identity" is offered to
simple-agent without offering the passphrase argument( the command is
"./simple-agent Identity=ap") ,the program cannot run smoothly. This error
not only exists in the modified simple-agent script but also exists in the
original simple-agent script.  As for this problem, some codes are added to
the input_passphrase() function of simple-agent :
 if not self.passphrase:
   print "passphrase is needed."
   response["Passphrase"] =
getpass.getpass("passphrase:")



   if not self.identity:
   print "identity is needed,the format
is Identity="
   response["Identity"] =
raw_input("answer:")
   Then, the script simple-agent can run smoothly,when run the
command "./simple-agent", the script can also receive the right passphrase.
when run the command "./simple-agent  Identity=ap", it will prompt you to
enter passphrase,no errors occur and the wifi can be connected.The changes
that have been made are all introduced as above.
   The modified script of simple-agent is attached.

Best Regards,
Chengyi Zhao


simple-agent-modified
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: [PATCH v3 05/15] session: Update sessions on config updates

2012-11-06 Thread Chengyi Zhao

Hi All,

 I write about two items in this letter. one is about the error
that the passphrase contains spaces can not be received correctly, a module
is imported to resolve this error. The other is about a new error
discovered during testing simple-agent,luckily, this discovered error is
also kicked.
simple-agent can not receive passwords that contains  spaces, for
example,  the following command:"./simple-agent Identity = ap, passphrase=
12345678 9 " will get errors, because the space between 8 and 9 is
recognized as the dividing sign of two different arguments. To solve this
problem, the getpass module is imported. The getpass module can receive any
character that gotten through the keyboard. The mainly changes are as below:
1. import getpass

2. print "%s Identity= need-Passphrase=yes
WPS=" % (sys.argv[0])

3. if arg.startswith("need-Passphrase="):
passphrase = getpass.getpass('passphrase:')

4. if arg.startswith("need-Password="):
response["Password"] = getpass.getpass('password:')

5.  elif arg.startswith("need-Passphrase="):
object.passphrase = getpass.getpass('passphrase:')

6.  elif arg.startswith("need-Password="):
object.password = getpass.getpass('password:')

so far,this problem is kicked, however, another error occurs. when running
the command "./simple-agent Identity=ap", the wifi cannot be connected
successfully. when running the command "./test-connman connect **" to
connect wifi, repeated and continuous error information :
   RequestInput (/net/connman/service
/wifi_00dbdf140abe_6170_managed_psk,dbus.Dictionary({dbus.String(u'Passphrase'):
dbus.Dictionary({dbus.String(u'Requirement'): dbus.String(u'mandatory',
variant_level=1), dbus.String(u'Type'): dbus.String(u'psk',
variant_level=1)}, signature=dbus.Signature('sv'), variant_level=1)},
signature=dbus.Signature('sv')))
^CTraceback (most recent call last)
 occur in the terminal where the simple-agent script runs. That is to say
,at the beginning if only the argument of "Identity" is offered to
simple-agent without offering the passphrase argument( the command is
"./simple-agent Identity=ap") ,the program cannot run smoothly. This error
not only exists in the modified simple-agent script but also exists in the
original simple-agent script.  As for this problem, some codes are added to
the input_passphrase() function of simple-agent :
 if not self.passphrase:
   print "passphrase is needed."
   response["Passphrase"] =
getpass.getpass("passphrase:")


 if not self.identity:
   print "identity is needed,the format
is Identity="
   response["Identity"] =
raw_input("answer:")
   Then, the script simple-agent can run smoothly,when run the
command "./simple-agent", the script can also receive the right passphrase.
when run the command "./simple-agent  Identity=ap", it will prompt you to
enter passphrase,no errors occur and the wifi can be connected.The changes
that have been made are all introduced as above.
   The modified script of simple-agent is attached.

Best Regards,
Chengyi Zhao



> __**_
> connman mailing list
> connman@connman.net
> http://lists.connman.net/**listinfo/connman<http://lists.connman.net/listinfo/connman>
>


simple-agent-modified
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: detect_newlink function.

2012-10-28 Thread Chengyi Zhao

Yes, I found out the solution in ConnMan 1.5, it is fixed in commit
01126286f96856aab6b0de171830f4e8e842e1da.

Thanks,
Chengyi

On Thu, Oct 25, 2012 at 7:46 PM, Patrik Flykt
wrote:

> On Thu, 2012-10-25 at 18:14 +0800, Chengyi Zhao wrote:
> > I don't know why the device of CONNMAN_DEVICE_TYPE_BLUETOOTH hasn't call
> > the function connman_device_register.
> > Now I want to fix a issue, the function detect_newlink has some relevance
> > to the solution of the issue(https://bugs.tizen.org/jira/browse/TIVI-211
> ).
>
> Please see https://bugs.meego.com/show_bug.cgi?id=25571. In general it
> makes sense to search bugs.meego.com also, since the bug might have been
> fixed upstream already.
>
> Cheers,
>
> Patrik
>
> ___
> connman mailing list
> connman@connman.net
> http://lists.connman.net/listinfo/connman
>
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

detect_newlink function.

2012-10-25 Thread Chengyi Zhao

Hi,

I don't know why the device of CONNMAN_DEVICE_TYPE_BLUETOOTH hasn't call
the function connman_device_register.
Now I want to fix a issue, the function detect_newlink has some relevance
to the solution of the issue(https://bugs.tizen.org/jira/browse/TIVI-211).
Please help me.

-
static void detect_newlink(unsigned short type, int index,
unsigned flags, unsigned change)
{
struct connman_device *device;
enum connman_device_type devtype;

DBG("type %d index %d", type, index);

devtype = __connman_rtnl_get_device_type(index);

switch (devtype) {
case CONNMAN_DEVICE_TYPE_UNKNOWN:
case CONNMAN_DEVICE_TYPE_VENDOR:
case CONNMAN_DEVICE_TYPE_WIMAX:
case CONNMAN_DEVICE_TYPE_BLUETOOTH:
case CONNMAN_DEVICE_TYPE_CELLULAR:
case CONNMAN_DEVICE_TYPE_GPS:
return;
case CONNMAN_DEVICE_TYPE_ETHERNET:
case CONNMAN_DEVICE_TYPE_WIFI:
case CONNMAN_DEVICE_TYPE_GADGET:
break;
}

device = find_device(index);
if (device != NULL)
return;

device = connman_inet_create_device(index);
if (device == NULL)
return;

if (connman_device_register(device) < 0) {
connman_device_unref(device);
return;
}

device_list = g_slist_append(device_list, device);
}
----

Best Regards,
Chengyi Zhao
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

65 matches

Mail list logo