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. connman wifi disconnect problem (KeithG)
2. Re: wireguard plugin doesn't load on musl (alpine linux)
(Sean Behan)
----------------------------------------------------------------------
Date: Sun, 21 Jun 2020 10:18:44 -0500
From: KeithG <[email protected]>
Subject: connman wifi disconnect problem
To: [email protected]
Message-ID:
<cag17s_n9ckvr_7bxuydvrj8yjnz2qzw08lqzkx5n0occker...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000000724405a899a5ae"
--00000000000000724405a899a5ae
Content-Type: text/plain; charset="UTF-8"
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>
--00000000000000724405a899a5ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>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. <br></div><div><br></div><div>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 wi=
thdrawn. I am running an openWRT router (other side of the DHCP equation) a=
nd this RPI MAC has a reserved ipv4 address on the router.</div><div><br></=
div><div>If I restart connman on the RPi, it will not regain connectivity o=
n 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 addr=
ess immediately and everything is back, but it will still not reconnect ove=
r wifi. I must reboot the RPi to get it to reconnect. I will see if I can f=
igure out how to have journal log more info on connman... <br></div><div><b=
r></div><div>Any idea what this could be? I will flash the router with ddwr=
t and see if it is the router.<br></div><div><br></div><div>In my /etc/conn=
man/main.conf, I have this:</div><div>[General]<br>FallbackNameservers =3D =
8.8.8.8,8.8.4.4<br>DefaultAutoConnectTechnologies =3D ethernet,wifi<br>Pref=
erredTechnologies =3D ethernet,wifi<br>AllowHostnameUpdates =3D false<br>Si=
ngleConnectedTechnology =3D true<br>AlwaysConnectedTechnologies =3D etherne=
t,wifi<br>AutoConnectRoamingServices =3D true<br></div><div><br></div><div>=
The journal shows this:</div><div>Jun 20 18:02:19 rune64 kernel: nfs: serve=
r 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, timed out<br>Jun 2=
0 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding, timed o=
ut<br></div><div>... lots of these 'not responding'...<br></div><di=
v>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 2601: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:f=
e52:ccd0/64 label (null)<br>Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leav=
ing 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]: Joi=
ning mDNS multicast group on interface wlan0.IPv6 with address fdcb:9d61:70=
f3:0:ba27:ebff:fe52:ccd0.<br>Jun 20 18:07:57 rune64 kernel: nfs: server 192=
.168.2.198 not responding, timed out<br>Jun 20 18:08:10 rune64 kernel: nfs:=
server 192.168.2.198 not responding, timed out<br>Jun 20 18:08:13 rune64 k=
ernel: nfs: server 192.168.2.198 not responding, timed out<br>Jun 20 18:08:=
14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255:: gw :: scope =
0 <UNIVERSE><br></div></div>
--00000000000000724405a899a5ae--
------------------------------
Date: Sun, 21 Jun 2020 18:40:01 -0400
From: "Sean Behan" <[email protected]>
Subject: Re: wireguard plugin doesn't load on musl (alpine linux)
To: "Daniel Wagner" <[email protected]>
Cc: [email protected]
Message-ID: <C3N53RR1SV2E.QO2UE058I1GG@komodo>
Content-Type: text/plain; charset=UTF-8
> I have seen this problem before but I can't remember what is
> exactly was. There was something about how the link loader
> is looking up symbols. Sorry can't remember right now.
Hi Daniel,
Where should I look to attempt to resolve this?
Would a full strace of connmand help diagnose where it's failing to look
up the symbols?
I'm not exactly sure what the issue is to be able to fix it. Is this
that ldd isn't finding the required libs during runtime, or that it's
not linking them properly initially?
Thanks again,
Sean
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 56, Issue 7
**************************************
