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. [PATCH] inet: Append correct attribute type for RTA_DST
(Daniel Wagner)
2. Re: Connman 1.37 source code different in YOCTO (Daniel Wagner)
3. Re: Wifi Scan Issues and Static IP for Wlan0 (Daniel Wagner)
4. Re: Failed to can wifi Invalid Sched_scan parameters (JH)
5. Re: Failed to can wifi Invalid Sched_scan parameters
(Daniel Wagner)
6. Re: Impossible to retry when entering wrong password with connmanctl.
(Maxime Roussin-Bélanger)
7. Re: Connman 1.37 source code different in YOCTO
(chaitanya cherukuri)
----------------------------------------------------------------------
Date: Thu, 6 Feb 2020 10:07:05 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH] inet: Append correct attribute type for RTA_DST
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
RTA_DST expects either struct in_addr or struct in6_addr and not
struct ai_addr.
The kernel complained with:
netlink: 'connmand': attribute type 1 has an invalid length.
Fixes: fad4070cf501 ("inet: Add function to return route to a given host")
---
src/inet.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/inet.c b/src/inet.c
index 99520e32170b..4c34143879b2 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -2624,11 +2624,21 @@ int __connman_inet_get_route(const char *dest_address,
rth->req.u.r.rt.rtm_scope = 0;
rth->req.u.r.rt.rtm_type = 0;
rth->req.u.r.rt.rtm_src_len = 0;
- rth->req.u.r.rt.rtm_dst_len = rp->ai_addrlen << 3;
rth->req.u.r.rt.rtm_tos = 0;
- __connman_inet_rtnl_addattr_l(&rth->req.n, sizeof(rth->req), RTA_DST,
- &rp->ai_addr, rp->ai_addrlen);
+ if (rp->ai_family == AF_INET) {
+ struct sockaddr_in *sin = (struct sockaddr_in *)rp->ai_addr;
+
+ rth->req.u.r.rt.rtm_dst_len = 32;
+ __connman_inet_rtnl_addattr_l(&rth->req.n, sizeof(rth->req),
+ RTA_DST, &sin->sin_addr, sizeof(sin->sin_addr));
+ } else if (rp->ai_family == AF_INET6) {
+ struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)rp->ai_addr;
+
+ rth->req.u.r.rt.rtm_dst_len = 128;
+ __connman_inet_rtnl_addattr_l(&rth->req.n, sizeof(rth->req),
+ RTA_DST, &sin6->sin6_addr, sizeof(sin6->sin6_addr));
+ }
freeaddrinfo(rp);
--
2.25.0
------------------------------
Date: Thu, 6 Feb 2020 10:24: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
> I didn't upgrade the complete Yocto distribution. I only upgraded connman
> and wpa_supplicant. I figured that the older version of wpa_supplicant was
> also installed and was causing the problems.
No surprise there.
> I will use iwmon for monitoring traffic between wpa_supplicant and
> kernel. Can I use wpa_supplicant version 2.6 for both connman 1.36?
wpa_supplicant 2.6 is really old and I woulnd't recommend it. Go for
the latest released version. Same goes for ConnMan.
> Can I replace wpa_supplicant with iwd for scanning?
No, either you use wpa_supplicant or iwd. You can't use both at the
same time.
Thanks,
Daniel
------------------------------
Date: Thu, 6 Feb 2020 10:30:51 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Wifi Scan Issues and Static IP for Wlan0
To: chaitanya cherukuri <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Feb 05, 2020 at 03:12:34PM -0500, chaitanya cherukuri wrote:
> Hello,
>
> I'm using connman version 1.36 and wpa_supplicant 2.36.
These are outdated versions. Please update to the last released
versions.
> I have a couple of issues with wifi scan and setting static IP address for
> wlan0 interface, could you please help me resolve this?
There are two ways for configuration, one is via D-Bus (this only
works if the services is available) and provisioning via
doc/config-format.txt
These methods are exclusive, means you can do one or the other. Not
both at the same time.
> 1. When I scan periodically ( every 10seconds), connman hangs up. Is there
> any
> configuration in connman or wpa_supplicant that can resolve this?
No idea what's going on. First, please update to the current
versions. In this case you should even update ConnMan to the current
head for debugging.
> 2. When the connected wireless network goes out of range or when i power
> off the wireless router to which I'm connected, wifi scan hangs up. this is
> the error message that I receive
> *"Error /net/connman/technology/wifi: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the message
> bus security policy blocked the re."*
Again, try with current versions.
> 3. How do I set up a static IP for wlan0 interface?
See above.
Thanks,
Daniel
------------------------------
Date: Thu, 6 Feb 2020 22:08:16 +1100
From: JH <[email protected]>
Subject: Re: Failed to can wifi Invalid Sched_scan parameters
To: Daniel Wagner <[email protected]>
Cc: linux-wireless <[email protected]>, connman
<[email protected]>
Message-ID:
<CAA=hcwq780vcx8kknpqgmtbzxqzbrgnzx6zghr0pawhg3o4...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On 2/4/20, Daniel Wagner <[email protected]> wrote:
> The 'Invalid Sched_scan parameters' indicates, wpa_supplicant is
> providing the wrong parameters. Best thing is to monitor between
> wpa_supplicant and kernel the netlink messages. iwmon is an excellent
> tool for this.
Thanks for the tip, I did not realize that connman is actually heavily
relied on wpa_supplicant, if I restarted wpa_supplicant, most of time
it popped up mwifiex_sdio messages, then the WiFi could be up:
$ systemctl restart wpa_supplicant
[ 371.617417] mwifiex_sdio mmc0:0001:1: info: 2
[ 371.647545] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:y
[ 371.726667] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[ 371.772758] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
But sometime when I restated wpa_supplicant, that message did not
come, the WiFi network was still down.
How is mwifiex_sdio related to wpa_supplicant?
Why it is nondeterministic, sometime restart wpa_supplicant could
bring mwifiex_sdio and WiFi up, something it couldn't?
I think mwifiex_sdio is the lowest layer to interact to WiFi modem, in
which circumstance it could bring WiFi modem up and in which
circumstance it couldn't?
That is far too unstable, I always thought I could rely on connman for
WiFi connection stability, but it seems that beyond connman capacity,
so what I can do when the WiFi is not up when restart wpa_supplicant
could not fix it?
Thank you very much Daniel.
Kind regards,
- jh
------------------------------
Date: Thu, 6 Feb 2020 14:14:55 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Failed to can wifi Invalid Sched_scan parameters
To: JH <[email protected]>
Cc: linux-wireless <[email protected]>, connman
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Thu, Feb 06, 2020 at 10:08:16PM +1100, JH wrote:
> On 2/4/20, Daniel Wagner <[email protected]> wrote:
> > The 'Invalid Sched_scan parameters' indicates, wpa_supplicant is
> > providing the wrong parameters. Best thing is to monitor between
> > wpa_supplicant and kernel the netlink messages. iwmon is an excellent
> > tool for this.
>
> Thanks for the tip, I did not realize that connman is actually heavily
> relied on wpa_supplicant, if I restarted wpa_supplicant, most of time
> it popped up mwifiex_sdio messages, then the WiFi could be up:
The good news here: with iwd ConnMan doesn't have to rely on
wpa_supplicant anymore. We had to add *a lot* of code to ConnMan
because of wpa_supplicant including a lot of work arounds. With iwd we
have a clear separation between the domains. So I strongly recommend
to look at iwd.
> $ systemctl restart wpa_supplicant
> [ 371.617417] mwifiex_sdio mmc0:0001:1: info: 2
> [ 371.647545] mwifiex_sdio mmc0:0001:1: info: associated to bssid
> 34:08:04:12:y
> [ 371.726667] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
> [ 371.772758] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
>
> But sometime when I restated wpa_supplicant, that message did not
> come, the WiFi network was still down.
You need to look at what your hardware/firmware, driver and
wpa_supplicant is going on. This is something ConnMan can't fix.
> How is mwifiex_sdio related to wpa_supplicant?
wpa_supplicant steers your WiFi chip.
> Why it is nondeterministic, sometime restart wpa_supplicant could
> bring mwifiex_sdio and WiFi up, something it couldn't?
That is the sad part about WiFi. The quality of the firmware, driver
and wpa_supplicant varies a lot. Some combination works great, others
are unusable.
> I think mwifiex_sdio is the lowest layer to interact to WiFi modem, in
> which circumstance it could bring WiFi modem up and in which
> circumstance it couldn't?
Sure, depending on the quality of the firmware and driver it might be
your main problem.
Don't get me wrong. I don't say your current setup is not good, but
from expierence firmware/drivers and wpa_supplicant tend to be
problematic.
iwd on the other hand is able to hide most of the nasty stuff for
ConnMan and I think in the long run it will be a lot more reliable
then wpa_supplicant was.
> That is far too unstable, I always thought I could rely on connman for
> WiFi connection stability, but it seems that beyond connman capacity,
> so what I can do when the WiFi is not up when restart wpa_supplicant
> could not fix it?
Try iwd.
Thanks,
Daniel
------------------------------
Date: Thu, 06 Feb 2020 14:57:32 -0000
From: Maxime Roussin-Bélanger <[email protected]>
Subject: Re: Impossible to retry when entering wrong password with
connmanctl.
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
For anyone finding this thread from search engines, there is a workaround patch
:
https://lists.01.org/hyperkitty/list/[email protected]/thread/HW72S2JI6KWBUILELJYNOFW6K6TS4DAZ/
------------------------------
Date: Thu, 6 Feb 2020 13:19:05 -0500
From: chaitanya cherukuri <[email protected]>
Subject: Re: Connman 1.37 source code different in YOCTO
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<calvd-wpgwqg4kuugvq6gt2+fkaxep55idegs1ybbfnjbdns...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000972492059dec4fc8"
--000000000000972492059dec4fc8
Content-Type: text/plain; charset="UTF-8"
On Thu, Feb 6, 2020 at 4:24 AM Daniel Wagner <[email protected]> wrote:
> > I didn't upgrade the complete Yocto distribution. I only upgraded
> connman
> > and wpa_supplicant. I figured that the older version of wpa_supplicant
> was
> > also installed and was causing the problems.
>
> No surprise there.
>
> > I will use iwmon for monitoring traffic between wpa_supplicant and
> > kernel. Can I use wpa_supplicant version 2.6 for both connman 1.36?
>
> wpa_supplicant 2.6 is really old and I woulnd't recommend it. Go for
> the latest released version. Same goes for ConnMan.
>
> > Can I replace wpa_supplicant with iwd for scanning?
>
> No, either you use wpa_supplicant or iwd. You can't use both at the
> same time
>
if I have both installed, do I need to create any services files, so
connman uses iwd to connect and scan wireless networks instead of
wpa_supplicant?
does iwd work connman version 1.36 or do I need to user 1.37?
> 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:
Sorry to get back to the source code difference. I cloned the master branch
from https://git.kernel.org/pub/scm/network/connman/connman.git/ and
compared with connman-1.37 ( from
https://git.kernel.org/pub/scm/network/connman/connman.git/refs/) which are
different. Is that what you expect>
> Thanks,
> Daniel
>
Thanks,
Chaitanya
--000000000000972492059dec4fc8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:comic sans ms,sans-serif;color:#3d85c6"><br></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 6, 2=
020 at 4:24 AM Daniel Wagner <<a href=3D"mailto:[email protected]";>wagi@mon=
om.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">>=C2=A0 I didn't upgrade the complete Yocto distribution. I on=
ly upgraded connman<br>
> and wpa_supplicant. I figured that the older version of wpa_supplicant=
was<br>
> also installed and was causing the problems.<br>
<br>
No surprise there.<br>
<br>
> I will use iwmon for monitoring traffic between wpa_supplicant and<br>
> kernel. Can I use wpa_supplicant version 2.6 for both connman 1.36?<br=
>
<br>
wpa_supplicant 2.6 is really old and I woulnd't recommend it. Go for<br=
>
the latest released version. Same goes for ConnMan.<br>
<br>
> Can I replace wpa_supplicant with iwd for scanning?<br>
<br>
No, either you use wpa_supplicant or iwd. You can't use both at the<br>
same time<br></blockquote><div>=C2=A0</div><div><div class=3D"gmail_default=
" style=3D""><span style=3D"font-family:"comic sans ms",sans-seri=
f;color:rgb(61,133,198)"></span><font color=3D"#000000" face=3D"arial, sans=
-serif">=C2=A0 if I have both installed, do I need to create any services f=
iles, so connman uses iwd to connect and scan wireless networks instead of =
wpa_supplicant?</font></div><div class=3D"gmail_default" style=3D""><font c=
olor=3D"#000000" face=3D"arial, sans-serif">=C2=A0 does iwd work connman ve=
rsion 1.36 or do I need to user 1.37?</font></div><div class=3D"gmail_defau=
lt" style=3D""><font color=3D"#000000" face=3D"arial, sans-serif">=C2=A0</f=
ont></div><div class=3D"gmail_default" style=3D""><span style=3D"color:rgb(=
80,0,80)">> I observed the connman 1.37 source code that YOCTO uses is d=
ifferent</span><br style=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80=
,0,80)">> from the source code in</span><br style=3D"color:rgb(80,0,80)"=
><span style=3D"color:rgb(80,0,80)">>=C2=A0</span><a href=3D"https://ker=
nel.googlesource.com/pub/scm/network/connman/connman/" rel=3D"noreferrer no=
referrer noreferrer noreferrer" target=3D"_blank">https://kernel.googlesour=
ce.com/pub/scm/network/connman/connman/</a><span style=3D"color:rgb(80,0,80=
)">.</span><br style=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(80,0,8=
0)">> To be more precise, I cannot find ipv4ll.c file in YOCTO source co=
de.</span><br style=3D"color:rgb(80,0,80)"><br style=3D"color:rgb(80,0,80)"=
><span style=3D"color:rgb(80,0,80)">=C2=A0 =C2=A0That is strange. I checkou=
t out the above repository and find the file:</span><br style=3D"color:rgb(=
80,0,80)">=C2=A0<br style=3D"color:rgb(80,0,80)"><span style=3D"color:rgb(8=
0,0,80)">=C2=A0 =C2=A0$ find -name ipv4ll.c</span><br style=3D"color:rgb(80=
,0,80)"><span style=3D"color:rgb(80,0,80)">=C2=A0 =C2=A0./gdhcp/ipv4ll.c</s=
pan><br style=3D"color:rgb(80,0,80)"><br style=3D"color:rgb(80,0,80)"><span=
style=3D"color:rgb(80,0,80)">=C2=A0 =C2=A0 I also cheked Yocto's ConnM=
an recipe:</span>=C2=A0</div><div class=3D"gmail_default" style=3D"">Sorry =
to get back to the source code difference. I cloned the master branch from=
=C2=A0<a href=3D"https://git.kernel.org/pub/scm/network/connman/connman.git=
/">https://git.kernel.org/pub/scm/network/connman/connman.git/</a>=C2=A0and=
compared with connman-1.37 ( from=C2=A0<a href=3D"https://git.kernel.org/p=
ub/scm/network/connman/connman.git/refs/">https://git.kernel.org/pub/scm/ne=
twork/connman/connman.git/refs/</a>) which are different. Is that what you =
expect></div><div class=3D"gmail_default" style=3D""><br></div><div clas=
s=3D"gmail_default" style=3D""><br></div></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Daniel<br>
</blockquote></div><br clear=3D"all"><div><div class=3D"gmail_default" styl=
e=3D""><font face=3D"arial, sans-serif" style=3D"" color=3D"#000000">Thanks=
,</font></div><div class=3D"gmail_default" style=3D""><font face=3D"arial, =
sans-serif" style=3D"" color=3D"#000000">Chaitanya</font></div><br></div></=
div>
--000000000000972492059dec4fc8--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 52, Issue 8
**************************************
