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] network: fixed connman_network_set_error when connect
during disconnect (Vasyl Vavrychuk)
2. Re: [PATCH] vpn: Handle stale task completions (Slava Monich)
3. RE: Retry NTP servers periodically on startup (Craig McQueen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 17 Apr 2018 02:30:57 +0300
From: Vasyl Vavrychuk <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: [PATCH] network: fixed connman_network_set_error when connect
during disconnect
Message-ID: <[email protected]>
If we call connect to wifi immidiatelly after disconnect with a right
interval then connect will be set pending because disconnect is in
progress.
After disconnect succeed connman_network_set_connected(networ, false)
will be called causing CONNMAN_NETWORK_ERROR_CONNECT_FAIL.
src/service.c:__connman_service_disconnect() service 0x5609fd6133e0
plugins/wifi.c:network_disconnect() network 0x5609fd612f60
src/network.c:connman_network_set_associating() network 0x5609fd612f60
associating 0
src/session.c:service_state_changed() service 0x5609fd6133e0 state 1
src/service.c:connect_service() service 0x5609fd6133e0
src/service.c:__connman_service_connect() service 0x5609fd6133e0 state idle
connect reason none -> user
src/network.c:__connman_network_connect() network 0x5609fd612f60
plugins/wifi.c:network_connect() network 0x5609fd612f60
src/network.c:connman_network_set_associating() network 0x5609fd612f60
associating 1
src/service.c:__connman_service_ipconfig_indicate_state() service
0x5609fd6133e0 (...) old state 1 (idle) new state 2 (association) type 1 (IPv4)
src/service.c:service_indicate_state() service 0x5609fd6133e0 old idle - new
association/idle => association
src/session.c:service_state_changed() service 0x5609fd6133e0 state 2
src/notifier.c:notify_idle_state() idle 0
src/manager.c:idle_state() idle 0
src/connection.c:__connman_connection_update_gateway() default (nil)
src/service.c:__connman_service_ipconfig_indicate_state() service
0x5609fd6133e0 (...) old state 1 (idle) new state 2 (association) type 2 (IPv6)
src/service.c:service_indicate_state() service 0x5609fd6133e0 old association -
new association/association => association
src/service.c:__connman_service_connect() service 0x5609fd6133e0 err -115
plugins/wifi.c:interface_state() wifi 0x5609fd6065c0 interface state 2
plugins/wifi.c:is_idle() state 7
src/network.c:connman_network_set_connected() network 0x5609fd612f60 connected
0/0 connecting 1 associating 1
src/network.c:connman_network_set_error() network 0x5609fd612f60 error 4
---
plugins/wifi.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 3ad60e21..dc08c6af 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2234,10 +2234,9 @@ static void disconnect_callback(int result,
GSupplicantInterface *interface,
return;
}
- if (wifi->network) {
+ if (wifi->network != wifi->pending_network)
connman_network_set_connected(wifi->network, false);
- wifi->network = NULL;
- }
+ wifi->network = NULL;
wifi->disconnecting = false;
wifi->connected = false;
@@ -2560,8 +2559,11 @@ static void interface_state(GSupplicantInterface
*interface)
default:
break;
}
- connman_network_set_connected(network, false);
- connman_network_set_associating(network, false);
+
+ if (network != wifi->pending_network) {
+ connman_network_set_connected(network, false);
+ connman_network_set_associating(network, false);
+ }
wifi->disconnecting = false;
start_autoscan(device);
--
2.11.0
------------------------------
Message: 2
Date: Tue, 17 Apr 2018 02:31:09 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] vpn: Handle stale task completions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 16/04/18 23:15, Daniel Wagner wrote:
> Hi Slava,
>
> On 04/13/2018 05:11 PM, Slava Monich wrote:
>> The task may die after we have already started the new one
>
> Can elaborate a bit here? It is really hard to figure out what is
> happening. I suppose it is a race somewhere.
>
Here are the events leading to the crash:
...
connman-vpnd[8015]: vpn/plugins/vpn.c:vpn_disconnect() disconnect provider
0x5694638:
...
connman-vpnd[8015]: src/task.c:connman_task_stop() task 0x5b2bdd0
connman-vpnd[8015]: src/task.c:check_kill() pid 11723 was not killed, retrying
after 2 sec
connman-vpnd[8015]: vpn/vpn-provider.c:do_connect() conn 0x50f0018 provider
0x5694638
connman-vpnd[8015]: vpn/vpn-provider.c:__vpn_provider_connect() provider
0x5694638
connman-vpnd[8015]: vpn/plugins/vpn.c:vpn_connect() data 0x5b1e7d0 state 4
...
connman-vpnd[8015]: src/task.c:connman_task_create()
connman-vpnd[8015]: src/task.c:connman_task_create() task 0x5f21a08
connman-vpnd[8015]: src/task.c:connman_task_set_notify() task 0x5f21a08
...
connman-vpnd[8015]: src/task.c:task_died() task 0x5b2bdd0 exit status 0
connman-vpnd[8015]: src/agent.c:connman_agent_cancel() context 0x5b326e0
connman-vpnd[8015]: vpn/plugins/vpn.c:vpn_died() provider 0x5694638 data
0x5b1e7d0
...
connman-vpnd[8015]: src/task.c:connman_task_destroy() task 0x5b2bdd0
connman-vpnd[8015]: src/task.c:free_task() task 0x5b2bdd0
...
connman-vpnd[8015]: vpn/plugins/vpn.c:vpn_notify() provider 0x5694638 driver
openvpn state 2
==8015== Invalid read of size 4
==8015== at 0x1C7C6: vpn_notify (vpn.c:279)
==8015== by 0x2152D: task_filter (task.c:452)
==8015== by 0x49B402F: dbus_connection_dispatch (dbus-connection.c:4703)
==8015== by 0x2E721: message_dispatch (mainloop.c:72)
==8015== by 0x4C6306F: g_main_dispatch (gmain.c:3154)
==8015== by 0x4C6306F: g_main_context_dispatch (gmain.c:3769)
==8015== by 0x4C6331D: g_main_context_iterate.isra.4 (gmain.c:3840)
==8015== by 0x4C6358F: g_main_loop_run (gmain.c:4034)
==8015== by 0x188E3: main (main.c:274)
==8015== Address 0x10 is not stack'd, malloc'd or (recently) free'd
In other words, we are stopping task A (0x5b2bdd0), then starting new
task B (0x5f21a08) reusing vpn_data allocated for task A (in
vpn/plugins/vpn.c:vpn_connect), then task A finally dies, which
deallocates vpn_data and only then we get a notification for task B but
vpn_data is already gone. Bummer!
Cheers,
-Slava
> Thanks,
> Daniel
>
>> ---
>> ? vpn/plugins/vpn.c | 5 +++++
>> ? 1 file changed, 5 insertions(+)
>>
>> diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
>> index aeb01d6..10548aa 100644
>> --- a/vpn/plugins/vpn.c
>> +++ b/vpn/plugins/vpn.c
>> @@ -133,6 +133,10 @@ void vpn_died(struct connman_task *task, int
>> exit_code, void *user_data)
>> ????? if (!data)
>> ????????? goto vpn_exit;
>> ? +??? /* The task may die after we have already started the new one */
>> +??? if (data->task != task)
>> +??????? goto done;
>> +
>> ????? state = data->state;
>> ? ????? stop_vpn(provider);
>> @@ -172,6 +176,7 @@ vpn_exit:
>> ????????? g_free(data);
>> ????? }
>> ? +done:
>> ????? connman_task_destroy(task);
>> ? }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20180417/f73d1c12/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 17 Apr 2018 07:48:05 +0000
From: Craig McQueen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: Retry NTP servers periodically on startup
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Daniel Wagner wrote:
> On 04/11/2018 03:59 AM, Craig McQueen wrote:
> > Daniel Wagner wrote:
> >> On 04/04/2018 09:56 AM, Craig McQueen wrote:
> >>>> Could you post the debug log of both tests? It sounds like that in
> >>>> the first case, ConnMan falls back to the aggressive retry loop and
> >>>> in the second case it doesn't happen.
> >>>
> >>> I sent the debug logs last week. Did that provide what you needed?
> >>
> >> Sorry about that. Got lost in the inbox. I did look at it but I need
> >> some more debug prints enabled. There isn't much information in the log.
> >> Could you try to get reproduced though this time with '-d
> >> src/ntp.c:src/timeserver.c' added to ConnMan command line?
> >
> > I found I needed to run:
> >
> > connmand -d ../git/src/ntp.c:../git/src/timeserver.c
> >
> > (I'm cross-compiling connman with the Yocto build system)
>
> Ah, the joy of Yocto :)
>
> > I'm attaching a log file of a test done today. The device is plugged
> > into an Ethernet switch. I unplugged the switch's upstream Internet
> > connection a few times, corresponding roughly to these two times in the
> log:
> >
> > Apr 11 10:37:50
> > Apr 11 10:56:49
> > Apr 11 11:01:42
> >
> > The last three lines of the log are most interesting, because it tries to
> > use
> an IPv6 address:
> >
> > Apr 11 11:01:42 wt000043 daemon.debug connmand[30185]:
> > ../git/src/timeserver.c:sync_next() Using timeserver
> > 2405:3c00:5200:100::1 Apr 11 11:01:42 wt000043 daemon.debug
> > connmand[30185]: ../git/src/ntp.c:start_ntp() server
> > 2405:3c00:5200:100::1 family 10 Apr 11 11:01:42 wt000043 daemon.err
> > connmand[30185]: Failed to open time server socket
> >
> > I wonder if the problem was related to it trying to use a server with
> > an IPv6 address, even though the device's kernel has no IPv6 capability.
>
> Yes, that sounds like the source your problem. Obviously, ConnMan
> shouldn't try to use an IPv6 time server if there is no support for IPv6 in
> the
> kernel.
>
> > After this, no further ntp/timeserver activity has occurred (for 54 minutes,
> at the time I'm writing this).
> >
> >>> I'm interested to fix this issue soon. Has any work been done on
> >>> this, or
> >> could I look into it?
> >>
> >> So far I haven't done anything. If you want to dig into the problem,
> >> I suggest to look at the debug output of ntp.c and timeserver.c and
> >> figure out why the state machine is not going back the initial state
> >> looking for a NTP server. From your description it seems we miss the
> >> some event and don't reset the state machine.
> >
> > I can consider looking into it. First, I would be very interested to
> > hear your thoughts on the IPv6 address in the above log.
>
> Can you try this one here?
>
> diff --git a/src/ntp.c b/src/ntp.c
> index 3c40f6210b81..335065f813e3 100644
> --- a/src/ntp.c
> +++ b/src/ntp.c
> @@ -531,7 +531,9 @@ static void start_ntp(struct ntp_data *nd)
> nd->transmit_fd = socket(family, SOCK_DGRAM | SOCK_CLOEXEC,
> 0);
>
> if (nd->transmit_fd <= 0) {
> - connman_error("Failed to open time server socket");
> + if (errno != EAFNOSUPPORT)
> + connman_error("Failed to open time server socket");
> + nd->cb(false, nd->user_data);
> return;
> }
Yes, that seems to fix the issue, based on my testing today. I'll give it more
testing in the next few days.
> If this works we should check all error paths in ntp and call the callback to
> let
> the upper layer know something didn't work out.
>
> > By the way, what might cause ConnMan to use a 16 second polling
> > interval, rather than the normal 1024 s (17 min) polling interval?
>
> The decode_msg() function in ntp.c extracts the polling interval from the
> message it receives. According the logs the server tell us to poll all 16
> seconds. Obviously, the ConnMan code could be buggy. Could you check
> with wireshark what the actually value in the frame is?
I think most likely it's correct, it's just that I don't have total control
over the NTP server on my network. I think it just started using a different
NTP server that was configured with that short polling interval. But if it
happens again, I'll check it with Wireshark.
Regards,
Craig McQueen
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 30, Issue 20
***************************************
