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: Doesn't connect to strongest wifi (Daniel Wagner)
2. Re: [PATCH] openvpn: Disable connection retry attempts when TCP is used
as transport
(Daniel Wagner)
3. Re: Impossible to retry when entering wrong password with connmanctl.
(Daniel Wagner)
4. Re: How to configure disconnected Ethernet? (Daniel Wagner)
5. Re: Connman 1.37 source code different in YOCTO (Daniel Wagner)
6. Re: Impossible to retry when entering wrong password with connmanctl.
(Maxime Roussin-Bélanger)
----------------------------------------------------------------------
Date: Sun, 2 Feb 2020 13:47:23 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Doesn't connect to strongest wifi
To: Torsten Wörtwein <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi Torsten,
On Wed, Jan 29, 2020 at 06:04:07PM -0500, Torsten Wörtwein wrote:
> I started IWD with
>
> sudo /usr/lib/iwd/iwd -d
>
> it then 'magically' (without connman) connected to the wifi - I assume it
> reads connman's settings for that.
iwd doesn't know about ConnMan's setting files. Are you sure ConnMan
was not running in the background? I don't see how else iwd figured
out the network settings. I assume you have a WPA2 enabled.
> IWD found all five wifis:
>
> src/station.c:station_add_seen_bss() Processing BSS '04:d9:f5:26:4f:69'
> with SSID: rivendell, freq: 5825, rank: 5932, strength: -6400
> src/station.c:station_add_seen_bss() Processing BSS 'fa:1a:67:32:fa:1f'
> with SSID: rivendell, freq: 2417, rank: 4707, strength: -3900
> src/station.c:station_add_seen_bss() Processing BSS 'fa:1a:67:32:fa:20'
> with SSID: rivendell, freq: 5500, rank: 4321, strength: -4400
> src/station.c:station_add_seen_bss() Processing BSS '04:d9:f5:26:4f:61'
> with SSID: rivendell, freq: 2427, rank: 4306, strength: -5500
> src/station.c:station_add_seen_bss() Processing BSS '04:d9:f5:26:4f:65'
> with SSID: rivendell, freq: 5240, rank: 2999, strength: -7000
> src/station.c:station_autoconnect_next() Considering autoconnecting to BSS
> '04:d9:f5:26:4f:69' with SSID: rivendell, freq: 5825, rank: 5932, strength:
> -6400
>
> 5500 and 2417 should be the repeater, to which I was closer at the moment.
> But it decided to connect to the router's high 5Ghz network.
If you are interested to see what's going on between iwd and the kernel
driver you can start the excellent iwmon by the iwd project.
> And then started connmand:
>
> sudo connmand -n -d plugins/iwd.c --wifi=iwd_agent
'--wifi=iwd_agent' doesn't really make anything. The '--wifi' option
is there to switch between the two APIs which wpa_supplicant
supports. So either nl80211 or WEXT. It doesn't do anything for the
iwd plugin.
> ** (connmand:1923): WARNING **: 17:38:47.484: error
> fi.w1.wpa_supplicant1.UnknownError
The wifi plugin should not run. That means wpa_supplicant might run in
the background. Shutdown wpa_supplicant and block it from auto
start. systemd might do something in the background.
Furthermore, you should propably disable the wifi plugin at boot up or
just don't enable it during build time.
wpa_supplicant and iwd should never run at the same time.
> It didn't print any frequency information.
>
> IWD seems to occasionally roam between the wifis :) For a brief period it
> picked 2417. Overall it highly prefers 5825 even if that is the farthest
> one away (to be fair, it worked - I didn't encounter connection issues).
Alright, this is sounds promising. Anyway, if you find anything not
working with iwd I am sure we get things sorted out as the iwd
developers are interested to get things fixed.
And from my point of view, I am interested to get things fixed in
ConnMan for iwd.
For wpa_supplicant, I don't want to invest more of my personal
time. Obviously, if someones sends fixes I am glad to except them. But
personally I wont to implement or fix bugs on it except minimal
maintaince work.
Thanks,
Daniel
------------------------------
Date: Sun, 2 Feb 2020 13:51:19 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] openvpn: Disable connection retry attempts when
TCP is used as transport
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Jan 31, 2020 at 03:43:13PM +0200, Jussi Laakkonen wrote:
> By default OpenVPN will retry the connection ad infinitum with TCP
> unless the limit is explicitly specified. The process is not restarted,
> nor is the error reported via management channel.
>
> When establishing the connection following is being output by OpenVPN
> if the TCP connection is reset, but none of this is reported back to
> ConnMan and OpenVPN keeps on trying:
>
> openvpn[18161]: Attempting to establish TCP connection with
> [AF_INET]<IP>:<PORT> [nonblock]
> openvpn[18161]: TCP connection established with [AF_INET]<IP>:<PORT>
> openvpn[18161]: TCP_CLIENT link local: (not bound)
> openvpn[18161]: TCP_CLIENT link remote: [AF_INET]<IP>:<PORT>
> openvpn[18161]: Connection reset, restarting [0]
> openvpn[18161]: SIGUSR1[soft,connection-reset] received, process restarting
> openvpn[18161]: Restart pause, 5 second(s)
>
> The delay will increase up to 300s. And the process may just keep on
> going if the connection is only reset.
>
> If the TCP connection breaks while OpenVPN is in connected state, and
> hostname of the VPN server is used following is output by OpenVPN - and
> still none of this is reported to ConnMan via management socket:
>
> openvpn[5639]: RESOLVE: Cannot resolve host address: <addr> (Temporary
> failure in name resolution)
> openvpn[5639]: RESOLVE: Cannot resolve host address: <addr> (Temporary
> failure in name resolution)
> openvpn[5639]: Could not determine IPv4/IPv6 protocol
> openvpn[5639]: SIGUSR1[soft,init_instance] received, process restarting
> openvpn[5639]: Restart pause, 160 second(s)
>
> After this network neturally ceases to work, DNS servers set cannot
> respond because there is no TCP connection to the VPN server and the VPN
> adapter set as default route will drop all packets because of that. For
> this reason it is better to let OpenVPN connect only once and report the
> error back to ConnMan. Therefore, disable connection retrying by setting
> the retry count to 1 (no retry).
As always, excellent commit message!
Thanks a lot!
Daniel
------------------------------
Date: Sun, 2 Feb 2020 15:40:00 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Impossible to retry when entering wrong password with
connmanctl.
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Max,
On Thu, Jan 30, 2020 at 01:39:50AM -0000, [email protected]
wrote:
> We are on version 1.37, we are using wpa_supplicant 2.9 with a
> kernel 4.19. When we are trying to use the connmanctl to connect to
> a protected wifi network it works well without a problem. However,
> if we make a mistake when we type the passphrase, it's impossible to
> retry. It does that to any network that we have tried.
Just to make sure I understand you correctly. You enter a passphrase
which is incorrect and after that you can't enter a new pasphrase?
> It is impossible to retry because for some reason when we are asked
> to retry
> (https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n365),
> this gets "cancel" by the agent
> (https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n254)
> and we lose the ability to retry forever for this network unless we
> delete the settings for this particular network. I never get a chance
> to enter yes or no. It never enters the callback
> (https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n312),
> that was set at line 365 in client/agent.c
I've tested the current head and version 1.37 on my system and there
was no problem with entering a wrong passhprase. If it's not correct I
get ask for a new pasphrase.
What do you mean by 'cancel'. Is the cancel from ConnMan?
> We looked at the d-bus-monitor and we get two types of error: `-3`
> and we do get a `16`, from 80211 AssocCode status code. -3 from what
> I can understand is internal.
Which communication are you monitoring? ConnMan - wpa_supplicant? You
can also turn up the debug level on ConnMan side by setting the
environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
connman log 'connmand -n -d'
Accoring the WiFi spec, 16 means group key handshake timeout.
I've tried to simulate the timeout by not entering a passphrase but
again, it's still working for me.
> Now, since I have not seen this issue from others, I'm wondering if
> it's related to our wifi chip misbehaving? I heard about a new thing
> called `iwd`, but I haven't tested it, maybe I could give this a
> shot.
I would give iwd a shot. Because debugging wpa_supplicant is no fun
(and I personally wont invest time in wpa_supplicant anymore) and the
iwd developers are helping to fix problems.
BTW, the iwd project has an excellent debugging tool (iwmon) for
looking at the kernel nl80211 interface. You can monitor all the
traffic between wpa_supplicant or iwd and kernel.
Thanks,
Daniel
------------------------------
Date: Sun, 2 Feb 2020 15:43:49 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: How to configure disconnected Ethernet?
To: Sergey Organov <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Sergey,
On Thu, Jan 30, 2020 at 05:13:04PM +0300, Sergey Organov wrote:
> The question is: how do I get Ethernet service configuration and/or
> re-configure it when there is no cable connected; for example, how do I
> change configuration so that at the next connect of the cable the
> service would use static IPv4 instead of DHCP?
For configuering non-existing networks you need to provision it. This
means you need to write a provisiong file for this. There is no D-Bus
interface for this. See the config-format.txt documentation:
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/config-format.txt
Thanks,
Daniel
------------------------------
Date: Sun, 2 Feb 2020 15:58:52 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Connman 1.37 source code different in YOCTO
To: chaitanya cherukuri <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Chaitanya,
On Thu, Jan 30, 2020 at 04:04:55PM -0500, chaitanya cherukuri wrote:
> I observed the connman 1.37 source code that YOCTO uses is different
> from the source code in
> https://kernel.googlesource.com/pub/scm/network/connman/connman/.
> To be more precise, I cannot find ipv4ll.c file in YOCTO source code.
That is strange. I checkout out the above repository and find the file:
$ find -name ipv4ll.c
./gdhcp/ipv4ll.c
I also cheked Yocto's ConnMan recipe:
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-connectivity/connman/connman/
There are no funky changes or patches on top. Not sure how ipv4ll.c
get's lost. Do you have some sort of license clearing robot removing
files in post processing? Anyway, the upstream mirror looks ok.
> I enabled the wlan0 interface but did not connect to any network. I
> see my log if filled with these messages:
> wlcore: firmware booted (Rev 6.3.10.0.142)
> IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> wlcore: down
>
> I didn't see this behavior on connman 1.35 version,
wlcore message is the driver message. This is not from ConnMan. Did
you upgrade the complete Yocto distribution? If so, did you upgrade
the kernel and wpa_supplicant as well? I ask because I don't think
ConnMan is making troubles. It's more likely an upgrade of the kernel
or wpa_supplicant breaks your setup.
Enable the debug level on ConnMan side by setting the environment
variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the connman log
'connmand -n -d'. Furthermore, there is iwmon from the iwd project
which is an excellent debugging tool for looking at the kernel nl80211
interface. You can monitor all the traffic between wpa_supplicant and
the kernel.
Thanks,
Daniel
------------------------------
Date: Sun, 2 Feb 2020 13:51:10 -0500
From: Maxime Roussin-Bélanger <[email protected]>
Subject: Re: Impossible to retry when entering wrong password with
connmanctl.
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<CAE=t-s6upnag_v8ykxcf8jne_pgennp5ccsq4yfn8jdmdtl...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000d6d06b059d9c4be9"
--000000000000d6d06b059d9c4be9
Content-Type: text/plain; charset="UTF-8"
On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <[email protected]> wrote:
>
> Hi Max,
>
> On Thu, Jan 30, 2020 at 01:39:50AM -0000, [email protected]
wrote:
> > We are on version 1.37, we are using wpa_supplicant 2.9 with a
> > kernel 4.19. When we are trying to use the connmanctl to connect to
> > a protected wifi network it works well without a problem. However,
> > if we make a mistake when we type the passphrase, it's impossible to
> > retry. It does that to any network that we have tried.
>
> Just to make sure I understand you correctly. You enter a passphrase
> which is incorrect and after that you can't enter a new pasphrase?
I can't enter a new passphrase, correct.
>
> > It is impossible to retry because for some reason when we are asked
> > to retry
> > (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n365
),
> > this gets "cancel" by the agent
> > (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n254
)
> > and we lose the ability to retry forever for this network unless we
> > delete the settings for this particular network. I never get a chance
> > to enter yes or no. It never enters the callback
> > (
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.c?h=1.37#n312
),
> > that was set at line 365 in client/agent.c
>
> I've tested the current head and version 1.37 on my system and there
> was no problem with entering a wrong passhprase. If it's not correct I
> get ask for a new pasphrase.
>
> What do you mean by 'cancel'. Is the cancel from ConnMan?
After the 'timeout', I get the output `Agent request cancelled by ConnMan`.
This cancel the retry prompt. Which I can see, but instead I'm shown the
`connmanctl>`
to enter a connmanctl command.
>
> > We looked at the d-bus-monitor and we get two types of error: `-3`
> > and we do get a `16`, from 80211 AssocCode status code. -3 from what
> > I can understand is internal.
>
> Which communication are you monitoring? ConnMan - wpa_supplicant? You
> can also turn up the debug level on ConnMan side by setting the
> environment variable CONNMAN_SUPPLICANT_DEBUG=1 and enabling the
> connman log 'connmand -n -d'
I monitored both.
>
> Accoring the WiFi spec, 16 means group key handshake timeout.
>
> I've tried to simulate the timeout by not entering a passphrase but
> again, it's still working for me.
I don't really know how WiFi works at a lower level, but it seems that if
I send the wrong password to the AP, the AP doesn't answer back. This
seems to trigger the timeout, or maybe the AP sends back a response, but
my device driver fails to handle the situation? We use brcm80211.
>
> > Now, since I have not seen this issue from others, I'm wondering if
> > it's related to our wifi chip misbehaving? I heard about a new thing
> > called `iwd`, but I haven't tested it, maybe I could give this a
> > shot.
>
> I would give iwd a shot. Because debugging wpa_supplicant is no fun
> (and I personally wont invest time in wpa_supplicant anymore) and the
> iwd developers are helping to fix problems.
>
> BTW, the iwd project has an excellent debugging tool (iwmon) for
> looking at the kernel nl80211 interface. You can monitor all the
> traffic between wpa_supplicant or iwd and kernel.
We've been using lttng to aggregate the tracing logs from
connman, wpa_supplicant and the kernel to have a complete
picture. This as not been easy to figure out what is going on, but
so far it seems to always relate to our hardware integration... (We have
other WiFi problems)
I'm not sure iwd will be helpful if our hardware integration is at
fault here... but it will give us more hints to where the problem is.
Thanks,
Max
>
> Thanks,
> Daniel
--000000000000d6d06b059d9c4be9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sun, Feb 2, 2020 at 9:40 AM Daniel Wagner <<=
a href=3D"mailto:[email protected]";>[email protected]</a>> wrote:<br>><br>&=
gt; Hi Max,<br>><br>> On Thu, Jan 30, 2020 at 01:39:50AM -0000, <a hr=
ef=3D"mailto:[email protected]";>maxime.roussinbelanger@gmail=
.com</a> wrote:<br>> > We are on version 1.37, we are using wpa_suppl=
icant 2.9 with a<br>> > kernel 4.19. When we are trying to use the co=
nnmanctl to connect to<br>> > a protected wifi network it works well =
without a problem. However,<br>> > if we make a mistake when we type =
the passphrase, it's impossible to<br>> > retry. It does that to =
any network that we have tried.<br>><br>> Just to make sure I underst=
and you correctly. You enter a passphrase<br>> which is incorrect and af=
ter that you can't enter a new pasphrase?<div><br></div><div>I can'=
t enter a new passphrase, correct.</div><div><br>><br>> > It is im=
possible to retry because for some reason when we are asked<br>> > to=
retry<br>> > (<a href=3D"https://git.kernel.org/pub/scm/network/conn=
man/connman.git/tree/client/agent.c?h=3D1.37#n365">https://git.kernel.org/p=
ub/scm/network/connman/connman.git/tree/client/agent.c?h=3D1.37#n365</a>),<=
br>> > this gets "cancel" by the agent<br>> > (<a hre=
f=3D"https://git.kernel.org/pub/scm/network/connman/connman.git/tree/client=
/agent.c?h=3D1.37#n254">https://git.kernel.org/pub/scm/network/connman/conn=
man.git/tree/client/agent.c?h=3D1.37#n254</a>)<br>> > and we lose the=
ability to retry forever for this network unless we<br>> > delete th=
e settings for this particular network. I never get a chance<br>> > t=
o enter yes or no. It never enters the callback<br>> > (<a href=3D"ht=
tps://git.kernel.org/pub/scm/network/connman/connman.git/tree/client/agent.=
c?h=3D1.37#n312">https://git.kernel.org/pub/scm/network/connman/connman.git=
/tree/client/agent.c?h=3D1.37#n312</a>),<br>> > that was set at line =
365 in client/agent.c<br>><br>> I've tested the current head and =
version 1.37 on my system and there<br>> was no problem with entering a =
wrong passhprase. If it's not correct I<br>> get ask for a new pasph=
rase.<br>><br>> What do you mean by 'cancel'. Is the cancel f=
rom ConnMan?</div><div><br></div><div>After the 'timeout', I get th=
e output `Agent request cancelled by ConnMan`.</div><div><br></div><div>Thi=
s cancel the retry prompt. Which I can see, but instead I'm shown the `=
connmanctl>`</div><div>to enter a connmanctl command.</div><div><br>>=
<br>> > We looked at the d-bus-monitor and we get two types of error:=
`-3`<br>> > and we do get a `16`, from 80211 AssocCode status code. =
-3 from what<br>> > I can understand is internal.<br>><br>> Whi=
ch communication are you monitoring? ConnMan - wpa_supplicant? You<br>> =
can also turn up the debug level on ConnMan side by setting the<br>> env=
ironment variable CONNMAN_SUPPLICANT_DEBUG=3D1 and enabling the<br>> con=
nman log 'connmand -n -d'</div><div><br></div><div>I monitored both=
.</div><div><br>><br>> Accoring the WiFi spec, 16 means group key han=
dshake timeout.<br>><br>> I've tried to simulate the timeout by n=
ot entering a passphrase but<br>> again, it's still working for me.<=
/div><div><br></div><div>I don't really know how WiFi works at a lower =
level, but it seems that if</div><div>I send the wrong password to the AP, =
the AP doesn't answer back. This</div><div>seems to trigger the timeout=
, or maybe the AP sends back a response, but</div><div>my device driver fai=
ls to handle the situation? We use=C2=A0brcm80211.</div><div><br>><br>&g=
t; > Now, since I have not seen this issue from others, I'm wonderin=
g if<br>> > it's related to our wifi chip misbehaving? I heard ab=
out a new thing<br>> > called `iwd`, but I haven't tested it, may=
be I could give this a<br>> > shot.<br>><br>> I would give iwd =
a shot. Because debugging wpa_supplicant is no fun<br>> (and I personall=
y wont invest time in wpa_supplicant anymore) and the<br>> iwd developer=
s are helping to fix problems.<br>><br>> BTW, the iwd project has an =
excellent debugging tool (iwmon) for<br>> looking at the kernel nl80211 =
interface. You can monitor all the<br>> traffic between wpa_supplicant o=
r iwd and kernel.</div><div><br></div><div>We've been using lttng to ag=
gregate the tracing logs from=C2=A0</div><div>connman, wpa_supplicant and t=
he kernel to have a complete</div><div>picture. This as not been easy to fi=
gure out what is going on, but</div><div>so far it seems to always relate t=
o our hardware integration... (We have</div><div>other WiFi problems)</div>=
<div><br></div><div>I'm not sure iwd will be helpful if our hardware in=
tegration is at</div><div>fault here... but it will give us more hints to w=
here the problem is.</div><div><br></div><div>Thanks,</div><div>Max</div><d=
iv>><br>> Thanks,<br>> Daniel</div></div>
--000000000000d6d06b059d9c4be9--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 52, Issue 1
**************************************
