Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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: connman wifi disconnect problem (KeithG)
2. [PATCH] ntp: Do not depend on the existence of a nameserver entry
(Markus Held)
----------------------------------------------------------------------
Date: Sun, 20 Sep 2020 10:44:37 -0500
From: KeithG <[email protected]>
Subject: Re: connman wifi disconnect problem
To: "Ryll, Jan (GED-SDD2)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID:
<CAG17S_PkY-g0QJmttGR_A+Z49VWxJYywYgcVhVzVLYeh=+b...@mail.gmail.com>
Content-Type: multipart/mixed; boundary="0000000000001f65ad05afc09d27"
--0000000000001f65ad05afc09d27
Content-Type: multipart/alternative; boundary="0000000000001f65ab05afc09d25"
--0000000000001f65ab05afc09d25
Content-Type: text/plain; charset="UTF-8"
On Mon, Jun 22, 2020 at 8:17 AM KeithG <[email protected]> wrote:
> Jan,
>
> Good call. I just built this for my architecture (aarch64) and installed
> it. Will see if there is any improvement.
>
> Thanks,
>
> Keith
>
> On Mon, Jun 22, 2020 at 4:01 AM Ryll, Jan (GED-SDD2) <[email protected]>
> wrote:
>
>> Hi Keith,
>>
>>
>>
>> its only a assumption, but it could be a firmware problem.
>>
>> We had also issues with connman and wifi but not on raspi. In our case it
>> was a cypress chipset.
>>
>>
>>
>> Regards
>>
>> Jan
>>
>>
>>
>>
>>
>> *From:* KeithG <[email protected]>
>> *Sent:* Sunday, June 21, 2020 5:19 PM
>> *To:* [email protected]
>> *Subject:* connman wifi disconnect problem
>>
>>
>>
>> I have been trying to diagnose a problem I am having with my RPis. I am
>> using iwd and connman to manage my ethernet connectivity. What I have
>> noticed is that after a while, sometimes, connectivity stops and I cannot
>> reconnect except after a reboot. I have seen this on RPi3's more so than
>> with RPi1/2. I have only noticed it with wlan0 and not with ethernet.
>>
>>
>>
>> From the journal, it looks like the network goes down (wlan0), connman
>> quickly notes it is down and pulls the ip address and sets the interface
>> down and then avahi identifies that it is down. It is interesting that
>> sometime before this, the ipv4 address was withdrawn. I am running an
>> openWRT router (other side of the DHCP equation) and this RPI MAC has a
>> reserved ipv4 address on the router.
>>
>>
>>
>> If I restart connman on the RPi, it will not regain connectivity on ipv4
>> or ipv6 on wlan0. If I reboot the router and then restart connman on the
>> RPi, it will not regain connectivity. I have to power cycle the RPI to get
>> it to connect again. If I plug in the ethernet cable, it grabs an address
>> immediately and everything is back, but it will still not reconnect over
>> wifi. I must reboot the RPi to get it to reconnect. I will see if I can
>> figure out how to have journal log more info on connman...
>>
>>
>>
>> Any idea what this could be? I will flash the router with ddwrt and see
>> if it is the router.
>>
>>
>>
>> In my /etc/connman/main.conf, I have this:
>>
>> [General]
>> FallbackNameservers = 8.8.8.8,8.8.4.4
>> DefaultAutoConnectTechnologies = ethernet,wifi
>> PreferredTechnologies = ethernet,wifi
>> AllowHostnameUpdates = false
>> SingleConnectedTechnology = true
>> AlwaysConnectedTechnologies = ethernet,wifi
>> AutoConnectRoamingServices = true
>>
>>
>>
>> The journal shows this:
>>
>> Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:02:20 rune64 systemd[1]:
>> dbus-org.freedesktop.timedate1.service: Succeeded.
>> Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>>
>> ... lots of these 'not responding'...
>>
>> Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
>> 2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
>> Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
>> 2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
>> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group
>> on interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
>> Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group
>> on interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
>> Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding,
>> timed out
>> Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route
>> 2601:241:4200:255:: gw :: scope 0 <UNIVERSE>
>>
>
I'm still struggling with this and have done a lot of poking at it and
posting Denis off list as well. This is what I 'think' I have learned.
1) iwd as standalone or with systemd-networkd/dhcpch or with NetworkManager
on x64 or on RPIs, all running arch linux, works great at version 1.9. If
the SSID 'goes away' and 'comes back' the computer will reconnect. every
time.
2) NetworkManager works well with iwd and as best I can tell, it will
reconnect via its interaction with iwd.
3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd
running standalone as I can edit the /var/lib/iwd/ssid.psk either manually
or through iwctl so that:
[Settings]
AutoConnect=true
In this setup, the computer reconnects at boot *and* when the SSID goes
away and comes back.
4) When connman manages iwd, though, I cannot edit the ssid.psk file and
have it stick. Though it connects every time at boot, it will not reconnect
if the ssid goes away and returns. This is with the headless rpis with
their broadcom cards and with a laptop runnning a full Arch Linux desktop
with an intel wifi card. One other thing I notice is that when it has
disconnected (SSID off then on), the 'connmanctl services' list is
incomplete. It definitely does not show all the currently available ssids
broadcasting. If I type 'connmanctl scan wifi' it will complete a scan
*and* reconnect. It is like connman gets stuck. and stops managing the wifi.
I also note that if the ethernet cable is plugged in on the RPIs then the
device is connected to the wifi ap then the ethernet cable is removed that
all internet connectivity ceases. Both interfaces go down and will not
reconnect requiring a reboot. It is tough for me to really query this as I
see it on my headless rpis and when the connectivity goes away, I have to
reboot to get it back. It did not behave like this with netctl nor does it
behave like this with systemd-networkd.
Also, on the rpis, I have noticed that connman can get into a state where
plugging in the ethernet cable results in nothing. connman will not bring
up the ethernet interface.
We have reworked a php interface from netctl tp work with connman for these
little rpi audio devices and I would love for it to work, but if a headless
device cannot reconnect when the ssid returns, it is a bit useless. Isn't
connman supposed to do this? There are many things I like about connman but
this seems like a basic function that seems to be broken and I am surprised
that I find very little info on it on the internet. The attached log is on
my laptop. I restarted the SSID radio at 10:06 and at 10:20, I did a
'connmanctl scan wifi' when it reconnected. I find this strange as
connman1.38 does not return with a 'scan completed' message but it does
reconnect. I see this behavior on the RPis as well.
I am running connman 1.38 and iwd 1.9 and have tried current gits of both
and also get the same result.
Any help?
Keith
--0000000000001f65ab05afc09d25
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 22, 2020 at 8:17 AM Keith=
G <<a href=3D"mailto:[email protected]";>[email protected]</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>Jan,</div><div><br></div><div>Good call. I just built this for my =
architecture (aarch64) and installed it. Will see if there is any improveme=
nt.</div><div><br></div><div>Thanks,</div><div><br></div><div>Keith<br></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Jun 22, 2020 at 4:01 AM Ryll, Jan (GED-SDD2) <<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang=3D"DE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)">Hi Keith,<u></u><u></u></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)" lang=3D"EN-US">its only a assump=
tion, but it could be a firmware problem.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)" lang=3D"EN-US">We had also issue=
s with connman and wifi but not on raspi. In our case it was a cypress chip=
set.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)" lang=3D"EN-US"><u></u>=C2=A0<u><=
/u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)" lang=3D"EN-US">Regards<u></u><u>=
</u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:"Cali=
bri",sans-serif;color:rgb(31,73,125)" lang=3D"EN-US">Jan<u></u><u></u>=
</span></p>
<p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11pt;font-family:"C=
alibri",sans-serif" lang=3D"EN-US">From:</span></b><span style=3D"font=
-size:11pt;font-family:"Calibri",sans-serif" lang=3D"EN-US"> Keit=
hG <<a href=3D"mailto:[email protected]"; target=3D"_blank">ys3al35l@gma=
il.com</a>>
<br>
<b>Sent:</b> Sunday, June 21, 2020 5:19 PM<br>
<b>To:</b> <a href=3D"mailto:[email protected]"; target=3D"_blank">connma=
[email protected]</a><br>
<b>Subject:</b> connman wifi disconnect problem<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=C2=A0<u></u></span></p>
<div>
<div>
<p class=3D"MsoNormal">I have been trying to diagnose a problem I am having=
with my RPis. I am using iwd and connman to manage my ethernet connectivit=
y. What I have noticed is that after a while, sometimes, connectivity stops=
and I cannot reconnect except after
a reboot. I have seen this on RPi3's more so than with RPi1/2. I have =
only noticed it with wlan0 and not with ethernet.
<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">From the journal, it looks like the network goes dow=
n (wlan0), connman quickly notes it is down and pulls the ip address and se=
ts the interface down and then avahi identifies that it is down. It is inte=
resting that sometime before this,
the ipv4 address was withdrawn. I am running an openWRT router (other side=
of the DHCP equation) and this RPI MAC has a reserved ipv4 address on the =
router.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">If I restart connman on the RPi, it will not regain =
connectivity on ipv4 or ipv6 on wlan0. If I reboot the router and then rest=
art connman on the RPi, it will not regain connectivity. I have to power cy=
cle the RPI to get it to connect again.
If I plug in the ethernet cable, it grabs an address immediately and every=
thing is back, but it will still not reconnect over wifi. I must reboot the=
RPi to get it to reconnect. I will see if I can figure out how to have jou=
rnal log more info on connman...
<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Any idea what this could be? I will flash the router=
with ddwrt and see if it is the router.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">In my /etc/connman/main.conf, I have this:<u></u><u>=
</u></p>
</div>
<div>
<p class=3D"MsoNormal">[General]<br>
FallbackNameservers =3D 8.8.8.8,8.8.4.4<br>
DefaultAutoConnectTechnologies =3D ethernet,wifi<br>
PreferredTechnologies =3D ethernet,wifi<br>
AllowHostnameUpdates =3D false<br>
SingleConnectedTechnology =3D true<br>
AlwaysConnectedTechnologies =3D ethernet,wifi<br>
AutoConnectRoamingServices =3D true<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">The journal shows this:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2=
.198 not responding, timed out<br>
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service: =
Succeeded.<br>
Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding, ti=
med out<br>
Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding, ti=
med out<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">... lots of these 'not responding'...<u></u>=
<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2=
.198 not responding, timed out<br>
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for 2=
601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.<br>
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address 2601:241:4200:255=
:ba27:ebff:fe52:ccd0/64 label (null)<br>
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on =
interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.<br=
>
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on =
interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.<br>
Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding, ti=
med out<br>
Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding, ti=
med out<br>
Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding, ti=
med out<br>
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255::=
gw :: scope 0 <UNIVERSE></p></div></div></div></div></blockquote></d=
iv></blockquote><div><br></div><div>I'm still struggling with this and =
have done a lot of poking at it and posting Denis off list as well. This is=
what I 'think' I have learned.</div><div><br></div><div>1) iwd as =
standalone or with systemd-networkd/dhcpch or with NetworkManager on x64 or=
on RPIs, all running arch linux, works great at version 1.9. If the SSID &=
#39;goes away' and 'comes back' the computer will reconnect. ev=
ery time. <br></div><div>2) NetworkManager works well with iwd and as best =
I can tell, it will reconnect via its interaction with iwd. <br></div><div>=
3) When I run systemd-networkd/dhcpcd with iwd, it is more like it iwd runn=
ing standalone as I can edit the /var/lib/iwd/ssid.psk either manually or t=
hrough iwctl so that:</div><div>[Settings]</div><div>AutoConnect=3Dtrue</di=
v><div>In this setup, the computer reconnects at boot *and* when the SSID g=
oes away and comes back. <br></div><div><br></div><div>4) When connman mana=
ges iwd, though, I cannot edit the ssid.psk file and have it stick. Though =
it connects every time at boot, it will not reconnect if the ssid goes away=
and returns. This is with the headless rpis with their broadcom cards and =
with a laptop runnning a full Arch Linux desktop with an intel wifi card. O=
ne other thing I notice is that when it has disconnected (SSID off then on)=
, the 'connmanctl services' list is incomplete. It definitely does =
not show all the currently available ssids broadcasting. If I type 'con=
nmanctl scan wifi' it will complete a scan *and* reconnect. It is like =
connman gets stuck. and stops managing the wifi.</div><div><br></div><div>I=
also note that if the ethernet cable is plugged in on the RPIs then the de=
vice is connected to the wifi ap then the ethernet cable is removed that al=
l internet connectivity ceases. Both interfaces go down and will not reconn=
ect requiring a reboot. It is tough for me to really query this as I see it=
on my headless rpis and when the connectivity goes away, I have to reboot =
to get it back. It did not behave like this with netctl nor does it behave =
like this with systemd-networkd. <br></div><div><br></div><div>Also, on the=
rpis, I have noticed that connman can get into a state where plugging in t=
he ethernet cable results in nothing. connman will not bring up the etherne=
t interface.</div><div><br></div><div>We have reworked a php interface from=
netctl tp work with connman for these little rpi audio devices and I would=
love for it to work, but if a headless device cannot reconnect when the ss=
id returns, it is a bit useless. Isn't connman supposed to do this? The=
re are many things I like about connman but this seems like a basic functio=
n that seems to be broken and I am surprised that I find very little info o=
n it on the internet. The attached log is on my laptop. I restarted the SSI=
D radio at 10:06 and at 10:20, I did a 'connmanctl scan wifi' when =
it reconnected. I find this strange as connman1.38 does not return with a &=
#39;scan completed' message but it does reconnect. I see this behavior =
on the RPis as well.<br></div><div><br></div><div>I am running connman 1.38=
and iwd 1.9 and have tried current gits of both and also get the same resu=
lt. <br></div><div><br></div><div>Any help?</div><div><br></div><div>Keith<=
br></div></div></div>
--0000000000001f65ab05afc09d25--
--0000000000001f65ad05afc09d27
Content-Type: text/plain; charset="US-ASCII";
name="connman_fail_to_reconnect.txt"
Content-Disposition: attachment; filename="connman_fail_to_reconnect.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_kfb9m6qv0>
X-Attachment-Id: f_kfb9m6qv0
U2VwIDIwIDEwOjA0OjM3IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtSWH0gMjY5
MSBwYWNrZXRzIDM2NzQ5MSBieXRlcwpTZXAgMjAgMTA6MDQ6Mzcga2VpdGgtZGVsbCBjb25ubWFu
ZFsxNDAwXTogd2xhbjAge1RYfSA1NDAgcGFja2V0cyA3NzU2NiBieXRlcwpTZXAgMjAgMTA6MDQ6
Mzcga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge3VwZGF0ZX0gZmxhZ3MgNjk2MzUg
PFVQLExPV0VSX1VQPgpTZXAgMjAgMTA6MDQ6Mzcga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTog
d2xhbjAge25ld2xpbmt9IGluZGV4IDQgYWRkcmVzcyBDMDpDQjozODoyRjpDNTo5MSBtdHUgMTUw
MApTZXAgMjAgMTA6MDQ6Mzcga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xp
bmt9IGluZGV4IDQgb3BlcnN0YXRlIDUgPERPUk1BTlQ+ClNlcCAyMCAxMDowNDozNyBrZWl0aC1k
ZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7YWRkfSByb3V0ZSBmZTgwOjogZ3cgOjogc2NvcGUg
MCA8VU5JVkVSU0U+ClNlcCAyMCAxMDowNDozNyBrZWl0aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3
bGFuMCB7Ulh9IDI2OTIgcGFja2V0cyAzNjc2NjAgYnl0ZXMKU2VwIDIwIDEwOjA0OjM3IGtlaXRo
LWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtUWH0gNTQyIHBhY2tldHMgNzc4NTQgYnl0ZXMK
U2VwIDIwIDEwOjA0OjM3IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHt1cGRhdGV9
IGZsYWdzIDY5Njk5IDxVUCxSVU5OSU5HLExPV0VSX1VQPgpTZXAgMjAgMTA6MDQ6Mzcga2VpdGgt
ZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4IDQgYWRkcmVzcyBDMDpD
QjozODoyRjpDNTo5MSBtdHUgMTUwMApTZXAgMjAgMTA6MDQ6Mzcga2VpdGgtZGVsbCBjb25ubWFu
ZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4IDQgb3BlcnN0YXRlIDYgPFVQPgpTZXAgMjAg
MTA6MDQ6Mzcga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2FkZH0gcm91dGUgMjYw
MDoxNzAwOjQzMjA6NmNhZjo6IGd3IDo6IHNjb3BlIDAgPFVOSVZFUlNFPgpTZXAgMjAgMTA6MDQ6
Mzkga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2FkZH0gYWRkcmVzcyAyNjAwOjE3
MDA6NDMyMDo2Y2FmOmMyY2I6MzhmZjpmZTJmOmM1OTEvNjQgbGFiZWwgKG51bGwpIGZhbWlseSAx
MApTZXAgMjAgMTA6MDQ6Mzkga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogRmFpbGVkIHRvIGZp
bmQgVVJMOmh0dHA6Ly9pcHY2LmNvbm5tYW4ubmV0L29ubGluZS9zdGF0dXMuaHRtbApTZXAgMjAg
MTA6MDQ6NDIga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2FkZH0gYWRkcmVzcyAx
OTIuMTY4LjIuNjkvMjQgbGFiZWwgd2xhbjAgZmFtaWx5IDIKU2VwIDIwIDEwOjA0OjQyIGtlaXRo
LWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHthZGR9IHJvdXRlIDE5Mi4xNjguMi4wIGd3IDAu
MC4wLjAgc2NvcGUgMjUzIDxMSU5LPgpTZXAgMjAgMTA6MDQ6NDIga2VpdGgtZGVsbCBjb25ubWFu
ZFsxNDAwXTogd2xhbjAge2FkZH0gcm91dGUgMTkyLjE2OC4yLjEgZ3cgMC4wLjAuMCBzY29wZSAy
NTMgPExJTks+ClNlcCAyMCAxMDowNDo0MiBrZWl0aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFu
MCB7YWRkfSByb3V0ZSAwLjAuMC4wIGd3IDE5Mi4xNjguMi4xIHNjb3BlIDAgPFVOSVZFUlNFPgpT
ZXAgMjAgMTA6MDQ6NDUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogRmFpbGVkIHRvIGZpbmQg
VVJMOmh0dHA6Ly9pcHY2LmNvbm5tYW4ubmV0L29ubGluZS9zdGF0dXMuaHRtbApTZXAgMjAgMTA6
MDQ6NDcga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2FkZH0gcm91dGUgMjEyLjIy
Ny44MS41NSBndyAxOTIuMTY4LjIuMSBzY29wZSAwIDxVTklWRVJTRT4KU2VwIDIwIDEwOjA0OjQ3
IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtkZWx9IHJvdXRlIDIxMi4yMjcuODEu
NTUgZ3cgMTkyLjE2OC4yLjEgc2NvcGUgMCA8VU5JVkVSU0U+ClNlcCAyMCAxMDowNjoxOSBrZWl0
aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7Ulh9IDMyNDMgcGFja2V0cyA0Mjg1NTQgYnl0
ZXMKU2VwIDIwIDEwOjA2OjE5IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtUWH0g
NjY3IHBhY2tldHMgOTUwMTIgYnl0ZXMKU2VwIDIwIDEwOjA2OjE5IGtlaXRoLWRlbGwgY29ubm1h
bmRbMTQwMF06IHdsYW4wIHtUWH0gNjY3IHBhY2tldHMgOTUwMTIgYnl0ZXMKU2VwIDIwIDEwOjA2
OjE5IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHt1cGRhdGV9IGZsYWdzIDQwOTkg
PFVQPgpTZXAgMjAgMTA6MDY6MTkga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25l
d2xpbmt9IGluZGV4IDQgYWRkcmVzcyBDMDpDQjozODoyRjpDNTo5MSBtdHUgMTUwMApTZXAgMjAg
MTA6MDY6MTkga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4
IDQgb3BlcnN0YXRlIDIgPERPV04+ClNlcCAyMCAxMDowNjoxOSBrZWl0aC1kZWxsIGNvbm5tYW5k
WzE0MDBdOiB3bGFuMCB7ZGVsfSBhZGRyZXNzIDE5Mi4xNjguMi42OS8yNCBsYWJlbCB3bGFuMApT
ZXAgMjAgMTA6MDY6MTkga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2RlbH0gcm91
dGUgMTkyLjE2OC4yLjAgZ3cgMC4wLjAuMCBzY29wZSAyNTMgPExJTks+ClNlcCAyMCAxMDowNjox
OSBrZWl0aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7ZGVsfSByb3V0ZSAyNjAwOjE3MDA6
NDMyMDo2Y2FmOjogZ3cgOjogc2NvcGUgMCA8VU5JVkVSU0U+ClNlcCAyMCAxMDowNjoxOSBrZWl0
aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7ZGVsfSByb3V0ZSBmZTgwOjogZ3cgOjogc2Nv
cGUgMCA8VU5JVkVSU0U+ClNlcCAyMCAxMDowNjoxOSBrZWl0aC1kZWxsIGNvbm5tYW5kWzE0MDBd
OiB3bGFuMCB7ZGVsfSBhZGRyZXNzIDI2MDA6MTcwMDo0MzIwOjZjYWY6YzJjYjozOGZmOmZlMmY6
YzU5MS82NCBsYWJlbCAobnVsbCkKU2VwIDIwIDEwOjIwOjI1IGtlaXRoLWRlbGwgY29ubm1hbmRb
MTQwMF06IHdsYW4wIHtSWH0gMzI0NCBwYWNrZXRzIDQyODY2NyBieXRlcwpTZXAgMjAgMTA6MjA6
MjUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge1RYfSA2NjcgcGFja2V0cyA5NTAx
MiBieXRlcwpTZXAgMjAgMTA6MjA6MjUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAg
e3VwZGF0ZX0gZmxhZ3MgNjk2MzUgPFVQLExPV0VSX1VQPgpTZXAgMjAgMTA6MjA6MjUga2VpdGgt
ZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4IDQgYWRkcmVzcyBDMDpD
QjozODoyRjpDNTo5MSBtdHUgMTUwMApTZXAgMjAgMTA6MjA6MjUga2VpdGgtZGVsbCBjb25ubWFu
ZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4IDQgb3BlcnN0YXRlIDUgPERPUk1BTlQ+ClNl
cCAyMCAxMDoyMDoyNSBrZWl0aC1kZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7YWRkfSByb3V0
ZSBmZTgwOjogZ3cgOjogc2NvcGUgMCA8VU5JVkVSU0U+ClNlcCAyMCAxMDoyMDoyNSBrZWl0aC1k
ZWxsIGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7Ulh9IDMyNDUgcGFja2V0cyA0Mjg4MzYgYnl0ZXMK
U2VwIDIwIDEwOjIwOjI1IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtUWH0gNjY5
IHBhY2tldHMgOTUzMDAgYnl0ZXMKU2VwIDIwIDEwOjIwOjI1IGtlaXRoLWRlbGwgY29ubm1hbmRb
MTQwMF06IHdsYW4wIHt1cGRhdGV9IGZsYWdzIDY5Njk5IDxVUCxSVU5OSU5HLExPV0VSX1VQPgpT
ZXAgMjAgMTA6MjA6MjUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xpbmt9
IGluZGV4IDQgYWRkcmVzcyBDMDpDQjozODoyRjpDNTo5MSBtdHUgMTUwMApTZXAgMjAgMTA6MjA6
MjUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge25ld2xpbmt9IGluZGV4IDQgb3Bl
cnN0YXRlIDYgPFVQPgpTZXAgMjAgMTA6MjA6MjYga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTog
d2xhbjAge2FkZH0gcm91dGUgMjYwMDoxNzAwOjQzMjA6NmNhZjo6IGd3IDo6IHNjb3BlIDAgPFVO
SVZFUlNFPgpTZXAgMjAgMTA6MjA6Mjgga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAg
e2FkZH0gYWRkcmVzcyAyNjAwOjE3MDA6NDMyMDo2Y2FmOmMyY2I6MzhmZjpmZTJmOmM1OTEvNjQg
bGFiZWwgKG51bGwpIGZhbWlseSAxMApTZXAgMjAgMTA6MjA6Mjgga2VpdGgtZGVsbCBjb25ubWFu
ZFsxNDAwXTogRmFpbGVkIHRvIGZpbmQgVVJMOmh0dHA6Ly9pcHY2LmNvbm5tYW4ubmV0L29ubGlu
ZS9zdGF0dXMuaHRtbApTZXAgMjAgMTA6MjA6MzAga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTog
d2xhbjAge2FkZH0gYWRkcmVzcyAxOTIuMTY4LjIuNjkvMjQgbGFiZWwgd2xhbjAgZmFtaWx5IDIK
U2VwIDIwIDEwOjIwOjMwIGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHthZGR9IHJv
dXRlIDE5Mi4xNjguMi4wIGd3IDAuMC4wLjAgc2NvcGUgMjUzIDxMSU5LPgpTZXAgMjAgMTA6MjA6
MzAga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xhbjAge2FkZH0gcm91dGUgMTkyLjE2OC4y
LjEgZ3cgMC4wLjAuMCBzY29wZSAyNTMgPExJTks+ClNlcCAyMCAxMDoyMDozMCBrZWl0aC1kZWxs
IGNvbm5tYW5kWzE0MDBdOiB3bGFuMCB7YWRkfSByb3V0ZSAwLjAuMC4wIGd3IDE5Mi4xNjguMi4x
IHNjb3BlIDAgPFVOSVZFUlNFPgpTZXAgMjAgMTA6MjA6MzQga2VpdGgtZGVsbCBjb25ubWFuZFsx
NDAwXTogRmFpbGVkIHRvIGZpbmQgVVJMOmh0dHA6Ly9pcHY2LmNvbm5tYW4ubmV0L29ubGluZS9z
dGF0dXMuaHRtbApTZXAgMjAgMTA6MjA6MzUga2VpdGgtZGVsbCBjb25ubWFuZFsxNDAwXTogd2xh
bjAge2FkZH0gcm91dGUgMjEyLjIyNy44MS41NSBndyAxOTIuMTY4LjIuMSBzY29wZSAwIDxVTklW
RVJTRT4KU2VwIDIwIDEwOjIwOjM1IGtlaXRoLWRlbGwgY29ubm1hbmRbMTQwMF06IHdsYW4wIHtk
ZWx9IHJvdXRlIDIxMi4yMjcuODEuNTUgZ3cgMTkyLjE2OC4yLjEgc2NvcGUgMCA8VU5JVkVSU0U+
Cgo=
--0000000000001f65ad05afc09d27--
------------------------------
Date: Mon, 21 Sep 2020 08:32:45 +0200
From: Markus Held <[email protected]>
Subject: [PATCH] ntp: Do not depend on the existence of a nameserver
entry
To: [email protected]
Cc: [email protected], Markus Held <[email protected]>
Message-ID: <[email protected]>
__connman_timeserver_sync() does not need to return -EINVAL if
there is no nameserver specified. This allows NTP to synchronise
with a timeserver configured as IP address and not require a
nameserver.
---
src/timeserver.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index decca15..7e4f88a 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -365,13 +365,12 @@ int __connman_timeserver_sync(struct connman_service
*default_service)
g_resolv_flush_nameservers(resolv);
nameservers = connman_service_get_nameservers(service);
- if (!nameservers)
- return -EINVAL;
-
- 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);
+ }
g_slist_free_full(timeservers_list, g_free);
--
2.7.4
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 59, Issue 20
***************************************
