Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. [PATCH] openvpn: Close stdout and stderr file descriptor from
child on exit (Daniel Wagner)
2. Re: [PATCH] openvpn: Close stdout and stderr file descriptor
from child on exit (Daniel Wagner)
3. unexpected disconnects in wifi (Vasiliy Tolstov)
4. Re: unexpected disconnects in wifi (Vasiliy Tolstov)
5. Hidden Wifi with several AP (Thomas Baron)
6. Re: unexpected disconnects in wifi (Patrik Flykt)
7. [PATCH v3] service: Block auto connect when connection is in
progress (Saurav Babu)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Dec 2016 18:07:27 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] openvpn: Close stdout and stderr file descriptor from
child on exit
Message-ID: <[email protected]>
We only added G_IO_IN to the watch and therefore never got the G_IO_HUP.
That leads to a busy loop because can_read_data always return true.
By adding G_IO_HUP & friends we really termanate now in
can_read_data. But we unrefed the channel one time to much.
These two bugs were introduced by 8e182879f709 ("openvpn: Use proper
logging function")
---
vpn/plugins/openvpn.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/vpn/plugins/openvpn.c b/vpn/plugins/openvpn.c
index 7d283b477635..e33950970b13 100644
--- a/vpn/plugins/openvpn.c
+++ b/vpn/plugins/openvpn.c
@@ -321,10 +321,8 @@ static gboolean can_read_data(GIOChannel *chan,
gchar *str;
gsize size;
- if (cond == G_IO_HUP) {
- g_io_channel_unref(chan);
+ if (cond & (G_IO_NVAL | G_IO_ERR | G_IO_HUP))
return FALSE;
- }
g_io_channel_read_line(chan, &str, &size, NULL, NULL);
cbf(str);
@@ -340,7 +338,8 @@ static int setup_log_read(int stdout_fd, int stderr_fd)
chan = g_io_channel_unix_new(stdout_fd);
g_io_channel_set_close_on_unref(chan, TRUE);
- watch = g_io_add_watch(chan, G_IO_IN, can_read_data, connman_debug);
+ watch = g_io_add_watch(chan, G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
+ can_read_data, connman_debug);
g_io_channel_unref(chan);
if (watch == 0)
@@ -348,7 +347,8 @@ static int setup_log_read(int stdout_fd, int stderr_fd)
chan = g_io_channel_unix_new(stderr_fd);
g_io_channel_set_close_on_unref(chan, TRUE);
- watch = g_io_add_watch(chan, G_IO_IN, can_read_data, connman_error);
+ watch = g_io_add_watch(chan, G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
+ can_read_data, connman_error);
g_io_channel_unref(chan);
return watch == 0? -EIO : 0;
--
2.9.3
------------------------------
Message: 2
Date: Mon, 19 Dec 2016 18:15:23 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] openvpn: Close stdout and stderr file descriptor
from child on exit
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
patch applied.
------------------------------
Message: 3
Date: Tue, 20 Dec 2016 23:53:00 +0300
From: Vasiliy Tolstov <[email protected]>
To: connman <[email protected]>
Subject: unexpected disconnects in wifi
Message-ID:
<CACaajQs=4dw1dq-gq1wrmadeliuxywhg8ydlkaeo69vmdi2...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I'm build for fedora connman 1.33 and have unexpected disconnects 5-10
times on each day:
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {RX} 1150129 packets
1426722614 bytes
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {TX} 734497 packets
106013237 bytes
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {update} flags 36867 <UP>
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 2 <DOWN>
Dec 20 21:03:13 computer connmand[3181]: Time request for server
172.16.1.1 failed (101/Network is unreachable)
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {del} address
172.16.1.4/24 label wlp2s0
Dec 20 21:03:13 computer connmand[3181]: wlp2s0 {del} route 172.16.1.0
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:13 computer connmand[3181]: Skipping disconnect of
6b65656e65746963_managed_psk, network is connecting.
Dec 20 21:03:13 computer connmand[3181]: ipconfig state 7 ipconfig method 1
Dec 20 21:03:14 computer connmand[3181]: ipconfig state 2 ipconfig method 1
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {RX} 1150129 packets
1426722614 bytes
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {TX} 734497 packets
106013237 bytes
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {update} flags 102403
<UP,LOWER_UP>
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:14 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 5 <DORMANT>
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {RX} 1150131 packets
1426722896 bytes
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {TX} 734499 packets
106013521 bytes
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {update} flags 102467
<UP,RUNNING,LOWER_UP>
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {newlink} index 3
address C8:FF:28:E2:57:49 mtu 1500
Dec 20 21:03:15 computer connmand[3181]: wlp2s0 {newlink} index 3
operstate 6 <UP>
Dec 20 21:03:15 computer connmand[3181]: ipconfig state 3 ipconfig method 1
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} address
172.16.1.4/24 label wlp2s0 family 2
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 172.16.1.0
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 172.16.1.1
gw 0.0.0.0 scope 253 <LINK>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 8.8.8.8 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 8.8.4.4 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route 0.0.0.0 gw
172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {add} route
82.165.8.211 gw 172.16.1.1 scope 0 <UNIVERSE>
Dec 20 21:03:16 computer connmand[3181]: wlp2s0 {del} route
82.165.8.211 gw 172.16.1.1 scope 0 <UNIVERSE>
--
Vasiliy Tolstov,
e-mail: [email protected]
------------------------------
Message: 4
Date: Wed, 21 Dec 2016 18:51:24 +0300
From: Vasiliy Tolstov <[email protected]>
To: Vasiliy Tolstov <[email protected]>
Cc: connman <[email protected]>
Subject: Re: unexpected disconnects in wifi
Message-ID:
<cacaajqt_j6thabqlvq--0qq8vab9_-pjmlvsrevdshyan5w...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2016-12-20 23:53 GMT+03:00 Vasiliy Tolstov <[email protected]>:
> I'm build for fedora connman 1.33 and have unexpected disconnects 5-10
> times on each day:
Anybody knows?
--
Vasiliy Tolstov,
e-mail: [email protected]
------------------------------
Message: 5
Date: Thu, 22 Dec 2016 10:40:23 +0100
From: Thomas Baron <[email protected]>
To: [email protected]
Subject: Hidden Wifi with several AP
Message-ID:
<CAL8jYX7b3wbG64Lw=v+Qu9tsjNXWQCyrzSMwXhR8709=dmf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm using connman (1.33) on a raspberry pi 3B to connect to a hidden wifi.
While this is working fine there is an strange behavior here : after the
connection is established (using wpa_supplicant), few seconds after connman
switch to another AP which is broadcasting the same SSID (actually there
are several AP on the same network at that place). Once this second
connection is made connman stays connected properly.
The WiFi configuration is set on /var/lib/connman/wifi.config (with Hidden
= true on the relevant service_wifi).
Extract of the relevant logs is below :
Dec 22 08:00:22 connmand[424]: Connection Manager version 1.33
connmand[424]: Adding configuration wifi
connmand[424]: Adding service configuration wifi_2458
[...]
systemd[1]: Started WPA supplicant.
connmand[424]: wlan0 {update} flags 36931 <UP,RUNNING>
wpa_supplicant[443]: wlan0: Trying to associate with 40:18:b1:0b:65:15
(SSID='name_of_the_ssid' freq=2437 MHz)
wpa_supplicant[443]: wlan0: Associated with 40:18:b1:0b:65:15
wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
40:18:b1:0b:65:15 [PTK=CCMP GTK=TKIP]
wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
40:18:b1:0b:65:15 completed [id=0 id_str=]
connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Dec 22 08:00:25 connmand[424]: ntp: time slew -0.215447 s
[...] (nothing here related to either connman or wpa_supplicant)
Dec 22 08:00:29 wpa_supplicant[443]: wlan0: Trying to associate with
00:19:77:3a:d1:54 (SSID='name_of_the_ssid' freq=2462 MHz)
connmand[424]: wlan0 {RX} 239 packets 79003 bytes
connmand[424]: Probably roaming right now! Staying connected...
wpa_supplicant[443]: wlan0: Associated with 00:19:77:3a:d1:54
wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
00:19:77:3a:d1:54 [PTK=CCMP GTK=TKIP]
wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
00:19:77:3a:d1:54 completed [id=0 id_str=]
connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Regarding the signal strengh with iwlist : Quality=36/70 Signal level=-74
dBm for 40:18:B1:0B:65:15 and Quality=46/70 Signal level=-64 dBm
for 00:19:77:3A:D1:54
So is it an expected behavior ? If yes why and is it connman,
wpa_supplicant or the AP which take the decision to switch AP ? Is there a
way to force connman to stay on the first AP and only switch if it doesn't
catch the signal anymore ?
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161222/34c31c4b/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 22 Dec 2016 11:43:54 +0200
From: Patrik Flykt <[email protected]>
To: Vasiliy Tolstov <[email protected]>
Cc: connman <[email protected]>
Subject: Re: unexpected disconnects in wifi
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-12-21 at 18:51 +0300, Vasiliy Tolstov wrote:
> 2016-12-20 23:53 GMT+03:00 Vasiliy Tolstov <[email protected]>:
> > I'm build for fedora connman 1.33 and have unexpected disconnects
> > 5-10
> > times on each day:
>
>
> Anybody knows?
export CONNMAN_SUPPLICANT_DEBUG=1, see README and enable also
wpa_supplicant logs. One source is errors when changing Access Points
if > 1 AP is servicing the WiFi network.
Cheers,
Patrik
------------------------------
Message: 7
Date: Thu, 22 Dec 2016 15:40:25 +0530
From: Saurav Babu <[email protected]>
To: [email protected]
Cc: [email protected], Saurav Babu <[email protected]>
Subject: [PATCH v3] service: Block auto connect when connection is in
progress
Message-ID:
<[email protected]>
Hi Patrik,
Resending my observation, please suggest
>> In the following scenario:
>> 1. Device is connected to AP in non hidden mode.
>> 2. Connection is initated to AP in hidden mode.
>> connman disconnects old service and tries to connect to new service.
>> But
>> for connecting hidden service it first scans the hidden AP and when
>> network is added for hidden AP then connection is tried. In the
>> meantime
>> normal AP got disconnected and was tried to autoconnect even before
>> hidden AP was scanned successfully.
>> This patch blocks auto connect when any service connection is in
>> progress and unblocks autoconnection after connection is started
>> or hidden wifi scan is completed and hidden AP is not found in the
>> scan list.
>> ---
>>
>> v3: Defer auto connect of services when one service is connecting
>> Allow auto connect of services when service connection fails with
>> error
>>
>>
>> src/connman.h | 2 ++
>> src/network.c | 4 ++++
>> src/service.c | 22 ++++++++++++++++++++--
>> 3 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/connman.h b/src/connman.h
>> index ce3ef8d..945518b 100644
>> --- a/src/connman.h
>> +++ b/src/connman.h
>> @@ -796,6 +796,8 @@ void __connman_service_notify(struct
>> connman_service *service,
>> int __connman_service_counter_register(const char *counter);
>> void __connman_service_counter_unregister(const char *counter);
>>
>> +void __connman_service_enable_autoconnect(bool autoconnect);
>> +
>> #include <connman/peer.h>
>>
>> int __connman_peer_init(void);
>> diff --git a/src/network.c b/src/network.c
>> index 2e423bc..e24970d 100644
>> --- a/src/network.c
>> +++ b/src/network.c
>> @@ -1370,6 +1370,8 @@ void connman_network_clear_hidden(void
>> *user_data)
>>
>> DBG("user_data %p", user_data);
>>
>> + __connman_service_enable_autoconnect(true);
>> +
>> /*
>> * Hidden service does not have a connect timeout so
>> * we do not need to remove it. We can just return
>> @@ -1389,6 +1391,8 @@ int connman_network_connect_hidden(struct
>> connman_network *network,
>>
>> DBG("network %p service %p user_data %p", network, service,
>> user_data);
>>
>> + __connman_service_enable_autoconnect(true);
>> +
>> if (!service)
>> return -EINVAL;
>>
>> diff --git a/src/service.c b/src/service.c
>> index f6a76f6..316581a 100644
>> --- a/src/service.c
>> +++ b/src/service.c
>> @@ -48,6 +48,7 @@ static unsigned int autoconnect_timeout = 0;
>> static unsigned int vpn_autoconnect_timeout = 0;
>> static struct connman_service *current_default = NULL;
>> static bool services_dirty = false;
>> +static bool allow_autoconnect = true;
>>
>> struct connman_stats {
>> bool valid;
>> @@ -3849,6 +3850,9 @@ void __connman_service_auto_connect(enum
>> connman_service_connect_reason reason)
>> if (autoconnect_timeout != 0)
>> return;
>>
>> + if (!allow_autoconnect)
>> + return;
>> +
>> if (!__connman_session_policy_autoconnect(reason))
>> return;
>>
>> @@ -4025,6 +4029,8 @@ static DBusMessage
>> *connect_service(DBusConnection *conn,
>>
>> index = __connman_service_get_index(service);
>>
>> + allow_autoconnect = false;
>> +
>> for (list = service_list; list; list = list->next) {
>> struct connman_service *temp = list->data;
>>
>> @@ -4042,8 +4048,10 @@ static DBusMessage
>> *connect_service(DBusConnection *conn,
>> err = -EINPROGRESS;
>>
>> }
>> - if (err == -EINPROGRESS)
>> + if (err == -EINPROGRESS) {
>> + allow_autoconnect = true;
>> return __connman_error_operation_timeout(msg);
>> + }
>>
>> service->ignore = false;
>>
>> @@ -4060,8 +4068,10 @@ static DBusMessage
>> *connect_service(DBusConnection *conn,
>> service->pending = NULL;
>> }
>>
>> - if (err < 0)
>> + if (err < 0) {
>> + allow_autoconnect = true;
>> return __connman_error_failed(msg, -err);
>> + }
>>
>> return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
>> }
>> @@ -5231,6 +5241,9 @@ static void request_input_cb(struct
>> connman_service *service,
>> service_complete(service);
>> __connman_connection_update_gateway();
>> }
>> +
>> + if (!service->hidden)
>> + allow_autoconnect = true;
>> }
>>
>> static void downgrade_connected_services(void)
>> @@ -5921,6 +5934,11 @@ static void prepare_8021x(struct
>> connman_service *service)
>> service-
>> >phase2);
>> }
>>
>> +void __connman_service_enable_autoconnect(bool autoconnect)
>> +{
>> + allow_autoconnect = autoconnect;
>> +}
>> +
>> static int service_connect(struct connman_service *service)
>> {
>> int err;
> This enabling and disabling of autoconnect looks a bit complicated.
> When the previous service is being disconnected, does the disconnection
> go like this:
> - src/service.c, 6132, err = service_connect(service);
> - src/service.c, 6072, err = __connman_network_connect(service->network);
> - src/network.c, 1446, __connman_device_disconnect(network->device);
> - src/device.c, 645, __connman_network_disconnect(network);
Currently disconnection goes like this:
- src/service.c, 4093, if (__connman_service_get_index(temp) == index &&
__connman_service_disconnect(temp) == -EINPROGRESS)
- src/service.c, 6198, err = __connman_network_disconnect(service->network);
> So in this case it should be the plugin itself that needs to decide
> whether and when another network needs to be disconnected? That way it
> can keep the network connected until it finds the hidden network it is
> looking for?
> With that the call to __connman_network_disconnect() could then be
> removed, but needs to move into the plugins? Or only look out for
> hidden WiFis?
I agree it is a good approach to allow plugins to disconnect
network when connection is started. This will require to remove
both the disconnect call by src/service.c when connection
is started.
We can add a check in network_connect() function of
plugins/wifi.c like below:
if (wifi->connected)
g_supplicant_interface_disconnect(wifi->interface, disconnect_callback,
wifi);
In case of hidden WiFis also above change would disconnect current WiFi only
when hidden WiFi is scanned and its connection is initiated.
Thanks,
Saurav
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 25
***************************************
