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. Re: [PATCH 01/27] shared: Add functions for random number
generation (Daniel Wagner)
2. Re: Setup without cable (Daniel Wagner)
3. Re: [PATCH] service: retry online check for IPv4 (Daniel Wagner)
4. Re: Connman very slow to reconnect after every warm reboot
(Daniel Wagner)
5. Re: [PATCH] service: retry online check for IPv4 (Daniel Mack)
6. [PATCH 0/1] Start timeserver after late DHCP configuration
(Robert Tiemann)
7. [PATCH 1/1] timeserver: List of nameservers may be empty
(Robert Tiemann)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Apr 2018 08:40:55 +0200
From: Daniel Wagner <[email protected]>
To: Christian Spielberger <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 01/27] shared: Add functions for random number
generation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
>> Prefix these function with 'random_':
>>
>> random_get()
>> random_cleanup()
>> random_delay_ms()
>>
>> Maybe someone has a better idea for 'random_get()'. I'd to have all the
>> shared code file properly prefixed to avoid clashes.
>>
>> Thanks,
>> Daniel
>
>
> Hi Daniel,
>
> now I found src/util.c which does nearly the same. I think, I should use this,
> right?
Yes, good point. That makes more sense. Having one random.h file for
those three functions might be a bit too much. We can still move things
around later if really needed.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 19 Apr 2018 08:43:52 +0200
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>, Vasiu Alexandru
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Setup without cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 04/19/2018 06:35 AM, Vasyl Vavrychuk wrote:
> You can try to write provision config file, see
> https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/config-format.txt
> for details.
In case the network/interface is not running, the only way to
pre-configure it, is to use the provisioning 'API' (config files).
------------------------------
Message: 3
Date: Thu, 19 Apr 2018 08:49:40 +0200
From: Daniel Wagner <[email protected]>
To: Daniel Mack <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: retry online check for IPv4
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 04/18/2018 11:55 AM, Daniel Mack wrote:
> Occasionally. wacky wifi connections might drop the first packets after
> they got their DHCP lease, but work stable afterwards. Be a bit more
> patient and retry the IPv4 online check in case it failed in the first
> attempt.
I'll give it a try over the next few days.
> The change is straight forward. A new function named
> __connman_service_wispr_start() is added to initialize the retry
> counters for both v4 and v6, and all former call sites of
> __connman_wispr_start() are now routed through
> __connman_service_wispr_start().
Hopefully it so simple. The main issue I see is that we have a bunch of
state machines coupled (IPv4, IPv6, WISPr, ...) and from experience it
means a lot of fun when things go wrong (IPv4 up, IPv6 up, WISPr start,
IPv4 down, WISPr stop, IPv6 down, IPv6 up, IPv4 up, ... things like this.).
Anyway, I really like the idea to get this thing fixed. So just give a
me a couple of days to toy around and see if things do not break apart
too horrible :)
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 19 Apr 2018 09:01:49 +0200
From: Daniel Wagner <[email protected]>
To: stef204 <[email protected]>, [email protected]
Subject: Re: Connman very slow to reconnect after every warm reboot
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 04/18/2018 09:48 PM, stef204 wrote:
> Connman 1.35
> Linux 4.15.15
> x86_64
> Systemd 238.76
>
> Been using Connman for 3 to 4 years now. Has always been reliable and stable.
>
> Recently, some annoying issue has crept up: when I (warm) reboot,
> connman does not reconnect immediately but lags significantly, is slow
> to (re)connect, even after I login to the system.
> Previously, Connman would already be on/connected once I logged in.
> (Referring to logging in to Linux system via login shell as normal
> user--Linux Console, no X, no display manager or DE interference.)
>
> Starting about 2 or 3 versions back, on reboot, it does not connect
> for some time--and lags significantly before it finally connects. I can
> check it with "ping 8.8.8.8" for example, and I get the usual "Network
> Unreachable", etc. It takes time for Connman to come back "up".
>
> I am thinking it "could " be related to the systemd connman.service
> unit but not sure; and I see that the seem to be provided upstream not
> by my distro.
Well, you could try the connman.service file a 3 releases ago to see if
it makes a difference. The only real thing I see in the git history (3-4
releases range) is
fe10df64f3f0 ("connman.service: Start ConnMan after systemd-sysusers")
diff --git a/src/connman.service.in b/src/connman.service.in
index 2198a198be43..09dfec98237b 100644
--- a/src/connman.service.in
+++ b/src/connman.service.in
@@ -3,7 +3,7 @@ Description=Connection service
DefaultDependencies=false
Conflicts=shutdown.target
RequiresMountsFor=@localstatedir@/lib/connman
-After=dbus.service network-pre.target
+After=dbus.service network-pre.target systemd-sysusers.service
Before=network.target multi-user.target shutdown.target
Wants=network.target
> % cat connman.service
> [Unit]
> Description=Connection service
> DefaultDependencies=false
> Conflicts=shutdown.target
> RequiresMountsFor=/var/lib/connman
> After=dbus.service network-pre.target systemd-sysusers.service
> Before=network.target multi-user.target shutdown.target
> Wants=network.target
>
> [Service]
> Type=dbus
> BusName=net.connman
> Restart=on-failure
> ExecStart=/usr/bin/connmand -n
> StandardOutput=null
> CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
> CAP_SYS_TIME CAP_SYS_MODULE
> ProtectHome=true
> ProtectSystem=true
>
> [Install]
> WantedBy=multi-user.target
>
> I cannot see anythin significant related to Connman in journalctl -b"
>
> Couple of lines from the journal:
> __connman_inet_get_pnp_nameservers: Cannot read /proc/net/pnp Failed to open
> file ?/proc/net/pnp?: No such file or directory
We just fixed that one. No real harm just an annoying message.
> Cannot create /var/run/connman/resolv.conf falling back to /etc/resolv.conf
That might be a problem. Although then if ConnMan wouldn't not be able
to setup the DNS resolver it would never work. Still check what happens
with the resolv.conf. It is a global resource NetworkManager and also
systemd-resolvd are trying to access. In the past ConnMan also just
grapped the file. Just recently we teached ConnMan to behave more
friendly and don't grab the file it all the time.
> Nothing in dmesg.
>
> I've done the usual searches, and looked at the official docs; and through
> recent mailing list archive posts but have not found a solution yet.
If that all failes try to create a log with timestamps. Maybe we can see
then what takes so long:
connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log
I suppose you don't need the ts for journald since it has its own
timestamp. In this case just start ConnMan with '-d' and look at the log
file.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 19 Apr 2018 09:01:57 +0200
From: Daniel Mack <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: retry online check for IPv4
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Daniel,
On Thursday, April 19, 2018 08:49 AM, Daniel Wagner wrote:
> On 04/18/2018 11:55 AM, Daniel Mack wrote:
>> Occasionally. wacky wifi connections might drop the first packets after
>> they got their DHCP lease, but work stable afterwards. Be a bit more
>> patient and retry the IPv4 online check in case it failed in the first
>> attempt.
>
> I'll give it a try over the next few days.
>
>> The change is straight forward. A new function named
>> __connman_service_wispr_start() is added to initialize the retry
>> counters for both v4 and v6, and all former call sites of
>> __connman_wispr_start() are now routed through
>> __connman_service_wispr_start().
>
> Hopefully it so simple. The main issue I see is that we have a bunch of
> state machines coupled (IPv4, IPv6, WISPr, ...) and from experience it
> means a lot of fun when things go wrong (IPv4 up, IPv6 up, WISPr start,
> IPv4 down, WISPr stop, IPv6 down, IPv6 up, IPv4 up, ... things like this.).
>
> Anyway, I really like the idea to get this thing fixed. So just give a
> me a couple of days to toy around and see if things do not break apart
> too horrible :)
Sure, no hurries :)
I've tested this with a Wifi which I cut off from its uplink
periodically, and it seems to do the right thing when it succeeds in the
2nd attempt etc. Also, the patch follows what is already there for IPv6.
But I'm not really familiar with the internals of connman, so of course
I might have missed something.
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 19 Apr 2018 12:21:22 +0200
From: Robert Tiemann <[email protected]>
To: [email protected]
Subject: [PATCH 0/1] Start timeserver after late DHCP configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
we have discovered a problem with NTP servers not being used under
certain conditions. Here is how to reproduce our problem:
1. Device is using Ethernet, cable is plugged into a switch. No other
technologies are involved.
2. Make sure there is no DHCP server on the network.
3. Start ConnMan and let it try to connect via Ethernet using DHCP.
Autoconfiguration kicks in after some time, and the IP address is
set to 169.254.x.y.
4. Start DHCP server.
5. After some time, ConnMan obtains a lease and configures the wired
service according to data received from the DHCP server.
6. All settings, including timeserver, are correctly configured now,
but the timeserver is not started.
7. Replugging the Ethernet cable triggers new DHCP configuration, but
this time the timeserver is started.
I have tracked down the problem to function timeserver_start() in
src/timeserver.c. At autoconfiguration time (step 3), there are no
nameservers configured and timeserver_start() returns early, leaving
the resolv pointer NULL. Consequently, __connman_timeserver_sync()
fails each time it is called.
At the time ConnMan obtains a proper DHCP lease, function
default_changed() in timeserver.c is *not* called, but
__connman_timeserver_sync() is. The latter fails because the resolv
pointer is still NULL. At this time you have a working IP connection,
but the timeserver is not running at all.
Now, I think the timeserver should work even without any nameservers
configured because the timeserver(s) could be provided as raw IP
address(es). This patch changes timeserver_start() such that the
nameservers are optional and resolv is always allocated.
I suspect, however, that the timeserver_notifier should be notified as
well after having obtained the DHCP lease, right? I don't know,
however, where and how this should be done, or even if it would be
correct in the first place.
Best regards,
Robert
Robert Tiemann (1):
timeserver: List of nameservers may be empty
src/timeserver.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
1.9.1
------------------------------
Message: 7
Date: Thu, 19 Apr 2018 12:23:11 +0200
From: Robert Tiemann <[email protected]>
To: [email protected]
Subject: [PATCH 1/1] timeserver: List of nameservers may be empty
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Even in case there is no nameserver configured, the timeserver code
can still work if the timeserver(s) is/are specified by IP address.
This commit also fixes a problem with the timeserver not being started
at all when obtaining a DHCP lease late after autoconfiguration.
---
src/timeserver.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index 55ec961..393c64c 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -426,8 +426,6 @@ static int timeserver_start(struct connman_service *service)
return -EINVAL;
nameservers = connman_service_get_nameservers(service);
- if (!nameservers)
- return -EINVAL;
/* Stop an already ongoing resolution, if there is one */
if (resolv && resolv_id > 0)
@@ -448,10 +446,12 @@ static int timeserver_start(struct connman_service
*service)
if (getenv("CONNMAN_RESOLV_DEBUG"))
g_resolv_set_debug(resolv, resolv_debug, "RESOLV");
- for (i = 0; nameservers[i]; i++)
- g_resolv_add_nameserver(resolv, nameservers[i], 53, 0);
+ if (nameservers) {
+ for (i = 0; nameservers[i]; i++)
+ g_resolv_add_nameserver(resolv, nameservers[i], 53, 0);
- g_strfreev(nameservers);
+ g_strfreev(nameservers);
+ }
return __connman_timeserver_sync(service);
}
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 30, Issue 24
***************************************
