12:48 p.m.
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.
% 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
Cannot create /var/run/connman/resolv.conf falling back to /etc/resolv.conf
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.
I'd appreciate any feedback on how to troubleshoot and resolve this issue.
Please let me know what additional info I may need to provide to help the
troubleshooting.
Thanks
12:01 a.m.
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
8:42 a.m.
19.04.2018, 01:01, "Daniel Wagner" <wagi(a)monom.org>:
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")
I have edited the service file and used an override on the
"After:systemd-sysusers" to remove it.
I used
# systemctl edit connman
to create a drop in override file which contains:
[Unit]
After=dbus.service network-pre.target
Is that correct of do I need to clear the After line first like this:
[Unit]
After=
After=dbus.service network-pre.targe
I rebooted a few times, and it does not seem to change anything.
If the above is correct, I will revert using #systemctl revert connman
And then try the log as you suggested:
# connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log
> 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.
systemd-resolved is inactive on my box and I do not have NetworkManager installed (only
libnm required by some iso imaging program.)
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.
I'll disable the connman systemd service and then will try either "# connmand -d
2>&1 | ts '[%H:%M:%.S]' | tee connman.log" or use "% journalctl
-f" and "% dmesg -w" to see what is gong on.
3:04 a.m.
Daniel, please see my comments below--I have included links to the log files.
19.04.2018, 01:01, "Daniel Wagner" <wagi(a)monom.org>:
> 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/>
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.)
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)
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?
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.
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.
5:42 a.m.
20.04.2018, 04:04, "stef204" <stef204(a)yandex.com>:
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)
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.
I am left with: the resolv.conf "issue" IF it is one, IOW cannot create
resolv.conf in /var/run/connman
Falling back to /etc/resolv.conf
But that file is empty--just contains this line:
# Generated by Connection Manager
AND left with the main issue I posted originally which is slow to (re)connect to network
after warm reboot.
I tried the git package (thinking there might be some updates in there which might help
resolve this but issue persists.)
1:33 p.m.
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" <wagi(a)monom.org>:
>> 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
1:48 a.m.
23.04.2018, 14:34, "Daniel Wagner" <wagi(a)monom.org>:
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.
10:26 p.m.
Hi,
>> 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).
Good to hear it works now.
> 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?
This feature is used for portal detection.
What does it add that would
be removed if disabled?
No WISPr support .
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.
ConnMan can log in automatically into portals for you, if (and that is a
big if) the portal is sporting proper WISPr protocols.
>> 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.
Yes please. It is useful to get such reports back.
Thanks,
Daniel
914
days inactive
923
days old
7 comments
2 participants
participants (2)
-
Daniel Wagner -
stef204