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] service: retry online check for IPv4 (Daniel Wagner)
2. Re: [PATCH 0/1] Start timeserver after late DHCP
configuration (Daniel Wagner)
3. [PATCH] ntp: Report error to upper layer (Daniel Wagner)
4. Re: Connman very slow to reconnect after every warm reboot
(Daniel Wagner)
5. Re: Setup without cable (Daniel Wagner)
6. Re: Setup without cable (Vasiu Alexandru)
7. Re: Connman very slow to reconnect after every warm reboot
(stef204)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Apr 2018 21:48:57 +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,
On 04/19/2018 09:01 AM, Daniel Mack wrote:
>> 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.
Seems to work, so I applied it.
> But I'm not really familiar with the internals of connman, so of course
> I might have missed something.
I thought this patch will change the online check to do the online check
permanently in the background. IIRC, the mer project has this logic
implemented in their version of ConnMan. Maybe we should just add it as
well. It seems to work for them. So if anyone wants to send a patch,
please go ahead.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 23 Apr 2018 22:05:36 +0200
From: Daniel Wagner <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/1] Start timeserver after late DHCP
configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Robert,
On 04/19/2018 12:21 PM, Robert Tiemann wrote:
> 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.
Thanks for tracking this done. Very helpful analysis. I've added the
above paragraphs to the commit message. It contains quite a lot of
valuable information, would be sad to lose it.
> 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.
Indeed, we need should kick timeserver to checkup on changes. I suspect,
this could be added at the dhcp_callback/success() code path in network.c.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 23 Apr 2018 22:20:49 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] ntp: Report error to upper layer
Message-ID: <[email protected]>
Inform the timeserver layer if there was an error. Without the error
reports the timeserver code assumes all is fine.
For example if the system does not suppoert IPv6 but we get an IPv6
NTP server address, start_ntp() will fail to create an IPv6 socket.
Let's report all error back so that timeserver is able to react on the
error.
Reported-by: Craig McQueen <[email protected]>
---
src/ntp.c | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/ntp.c b/src/ntp.c
index 3c40f6210b81..51ba9aac966e 100644
--- a/src/ntp.c
+++ b/src/ntp.c
@@ -195,6 +195,7 @@ static void send_packet(struct ntp_data *nd, struct
sockaddr *server,
addr = (void *)&nd->timeserver_addr.sin6_addr;
} else {
connman_error("Family is neither ipv4 nor ipv6");
+ nd->cb(false, nd->user_data);
return;
}
@@ -221,6 +222,7 @@ static void send_packet(struct ntp_data *nd, struct
sockaddr *server,
if (len != sizeof(msg)) {
connman_error("Broken time request for server %s",
inet_ntop(server->sa_family, addr, ipaddrstring,
sizeof(ipaddrstring)));
+ nd->cb(false, nd->user_data);
return;
}
@@ -531,36 +533,31 @@ 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");
- return;
+ if (errno != EAFNOSUPPORT)
+ connman_error("Failed to open time server socket");
}
if (bind(nd->transmit_fd, (struct sockaddr *) addr, size) < 0) {
connman_error("Failed to bind time server socket");
- close(nd->transmit_fd);
- return;
+ goto err;
}
if (family == AF_INET) {
if (setsockopt(nd->transmit_fd, IPPROTO_IP, IP_TOS, &tos,
sizeof(tos)) < 0) {
connman_error("Failed to set type of service option");
- close(nd->transmit_fd);
- return;
+ goto err;
}
}
if (setsockopt(nd->transmit_fd, SOL_SOCKET, SO_TIMESTAMP, ×tamp,
sizeof(timestamp)) < 0) {
connman_error("Failed to enable timestamp support");
- close(nd->transmit_fd);
- return;
+ goto err;
}
channel = g_io_channel_unix_new(nd->transmit_fd);
- if (!channel) {
- close(nd->transmit_fd);
- return;
- }
+ if (!channel)
+ goto err;
g_io_channel_set_encoding(channel, NULL, NULL);
g_io_channel_set_buffered(channel, FALSE);
@@ -576,6 +573,14 @@ static void start_ntp(struct ntp_data *nd)
send:
send_packet(nd, (struct sockaddr*)&ntp_data->timeserver_addr,
NTP_SEND_TIMEOUT);
+ return;
+
+err:
+ if (nd->transmit_fd > 0)
+ close(nd->transmit_fd);
+
+ nd->cb(false, nd->user_data);
+ return;
}
int __connman_ntp_start(char *server, __connman_ntp_cb_t callback,
--
2.14.3
------------------------------
Message: 4
Date: Mon, 23 Apr 2018 22:33:57 +0200
From: Daniel Wagner <[email protected]>
To: stef204 <[email protected]>, "[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/20/2018 12:04 PM, stef204 wrote:
> Daniel, please see my comments below--I have included links to the log files.
>
> 19.04.2018, 01:01, "Daniel Wagner" <[email protected]>:
>
>>> ?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.
>>
>>
>> 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
>>
>
> Here is the result of:
> # journalctl -f
> <https://paste.xinu.at/zyt/>
I don't see any thing really strange in the log. The only thing I notice
the wpa_s calls. Are you sure that you didn't upgrade wpa_s along with
ConnMan. If possible try different version of it. It is a constant
source of troubles.
> And here is the result of:
> %dmesg -w
> <https://paste.xinu.at/AMGz1/>
>
> (I have redacted some addresses out, hope it does not make it more difficult
> to read.)
That's okay.
> I see one error besides the resolv.conf error above:
> connmand[5630]: Failed to set domainname to xxxx.box (this would be the
> domain name of my router)
You can disable this in the main config. ConnMan wants to set the
hostname given by DHCP.
> I don't know why it throws that error off and if it has any importance/impact.
> The hostname on my box is different than the one on the router but locally it
> seems set normally, i can see it when checking:
>
> % hostname
> or
> % hostnamectl status
>
> Incidentally, I see these 2 lines in the log which are of concern:
>
> wlp5s0 {add} route 212.227.81.55 gw 192.168.178.1 scope 0 <UNIVERSE>
> Apr 20 11:18:14 somelinux connmand[15615]: wlp5s0 {del} route 212.227.81.55
> gw 192.168.178.1 scope 0 <UNIVERSE>
>
> What is 212.227.81.55? Is this related to the small check connman does when
> starting?
That's the online check. In the README should be some pointers on it.
And you can disable it if want.
> Please let me know if you see anything odd or weird in the logs. I don't.
> The quality of my connection is also degrading as of late and when I check
> with another box not running connman, it seems that my own box connects much
> slower--from ping tests.
Over wifi I presume. Well, check what wpa_s is doing and the drivers. It
sounds like some regression in the drivers.
> This, of course, could be due to problems at my ISP. However, what is weird
> is that when I do the same ping from another box (not running connman)
> CONCURRENTLY, the stats at times, are much better. I mean ping stats at
> 1500ms on my box and 25ms on the other box, pinging 4.2.2.2.
>
> There could be something misconfigured on my box OR on my router and if so,
> it escapes me at the moment. I do get a fix IP address assigned by my router
> and that should not and has never run interference in anyway (I don't see why
> it would.)
>
> Thanks for any feedback or suggestions you can provide.
Sorry can't really help. It sound really like a driver/wpa_s thingy for
me. Though I can be wrong. The only advice I can give is to try out
different combination the kernel, wpa_s and ConnMan because there is
anything really obvious wrong. BTW, you can also enable some more
logging on wpa_s.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 23 Apr 2018 22:35:05 +0200
From: Daniel Wagner <[email protected]>
To: Vasiu Alexandru <[email protected]>
Cc: Vasyl Vavrychuk <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Setup without cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 04/20/2018 03:16 PM, Vasiu Alexandru wrote:
> It's working. But to get the DNS Servers of such an interface? (if I
> won't set it in the provisioning file) Because resolv.conf is overridden
> by connman.
Not sure I understood your question correct. But if you want to know
which DNS server is used you can query ConnMan via the D-Bus interface.
Thanks,
Daniel
------------------------------
Message: 6
Date: Mon, 23 Apr 2018 22:30:12 +0000
From: Vasiu Alexandru <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Vasyl Vavrychuk <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Setup without cable
Message-ID:
<cafw0yttrqjcpdeht-otefpet6kaynr0up-bdsm34huuh+oq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I think that is possible just a service. Am I right? If I have an interface
which is not a service (not connected with a cable), how to get DNS servers
from the system if connman override resolv.conf file?
Alex
?n lun., 23 apr. 2018 la 23:35, Daniel Wagner <[email protected]> a scris:
> On 04/20/2018 03:16 PM, Vasiu Alexandru wrote:
> > It's working. But to get the DNS Servers of such an interface? (if I
> > won't set it in the provisioning file) Because resolv.conf is overridden
> > by connman.
>
> Not sure I understood your question correct. But if you want to know
> which DNS server is used you can query ConnMan via the D-Bus interface.
>
> Thanks,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20180423/294a5b20/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 24 Apr 2018 02:48:58 -0600
From: stef204 <[email protected]>
To: "[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
23.04.2018, 14:34, "Daniel Wagner" <[email protected]>:
>
> I don't see any thing really strange in the log. The only thing I notice
> the wpa_s calls. Are you sure that you didn't upgrade wpa_s along with
> ConnMan. If possible try different version of it. It is a constant
> source of troubles.
>
Last supplicant "upgrade" (more of a distro upgrade than upstream) is Oct 2017
so I don't quite remember this "slowness to reconnect" issue going back that
far.
>> ?And here is the result of:
>> ?%dmesg -w
>
>> ?I see one error besides the resolv.conf error above:
>> ?connmand[5630]: Failed to set domainname to xxxx.box (this would be the
>> domain name of my router)
>
> You can disable this in the main config. ConnMan wants to set the
> hostname given by DHCP.
>
It's fixed as I mentioned in another reply:
For the record, I have fixed the above "secondary issue" by adding
CAP_SYS_ADMIN to the connman.service unit CapabilityBoundingSet line
I no longer get the " connmand[5630]: Failed to set domainname to xxxx.box "
error.
it now works as expected. I will leave it alone (default is enabled I believe).
>
> That's the online check. In the README should be some pointers on it.
> And you can disable it if want.
>
Yes, I figured as much. Before considering disabling it, what is the value of
this online check for me as a user? What does it add that would be removed if
disabled? I have read the docs but don't really see what is vital or
significant there; I do travel so have to connect from different places and
using different networks.
>> ?Please let me know if you see anything odd or weird in the logs. I don't.
>> ?The quality of my connection is also degrading as of late and when I check
>> with another box not running connman, it seems that my own box connects much
>> slower--from ping tests.
>
> Over wifi I presume. Well, check what wpa_s is doing and the drivers. It
> sounds like some regression in the drivers.
I think it may be due to a regression or bug in the kernel actually, from some
additional searched I've done. Will continue debugging and post what I find
out (if anything) here.
>
> Sorry can't really help.
You are helping, and your feedback is appreciated. Thanks again.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 30, Issue 28
***************************************
