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: [PATCH 2/3 v2] vpn-provider: Implement setting of multiple VPN
properties with one call
(Daniel Wagner)
2. Re: wifi AP disconnect(disconnect reason code 1) (Daniel Wagner)
3. Re: Connection to WPA fails following connect-failed error
(Daniel Wagner)
4. Re: wifi AP disconnect(disconnect reason code 1) (Deepu Paul)
5. Re: [PATCH v3 0/5] Simplify settings save code (Daniel Wagner)
6. Re: [PATCH v3 0/5] Simplify settings save code (Daniel Wagner)
7. [PATCH] vpn-provider: Interpret VPN route ProtocolFamily as number
(David Llewellyn-Jones)
8. Re: [PATCH v3 0/5] Simplify settings save code (Daniel Wagner)
9. Re: [PATCH] vpn-provider: Interpret VPN route ProtocolFamily as number
(Daniel Wagner)
----------------------------------------------------------------------
Date: Fri, 10 Jan 2020 09:31:01 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 2/3 v2] vpn-provider: Implement setting of
multiple VPN properties with one call
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 31.12.19 10:27, Jussi Laakkonen wrote:
> I know, that would create duplicate content sent to clients and more
> noise in D-Bus but it would be in line with the specs. Any thoughts?
If you have an use case where it really helps (not just nice to have) I
think I could be convinced. The main issue with signals is that we CPU
load without knowing if any one on the bus is interested in. For battery
powered devices this is usually a bad thing.
Thanks,
Daniel
------------------------------
Date: Fri, 10 Jan 2020 09:40:40 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: wifi AP disconnect(disconnect reason code 1)
To: Deepu Paul <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi
Please don't top post and also send text emails.
On Thu, Jan 09, 2020 at 04:36:16PM +0000, Deepu Paul wrote:
> May i know if you a chance to look the logs below please?
Yes.
> > Attaching both connman and wpa_supplicant logs,
> >
> > There are 2 disconnects with reason code 1, in the first one it
> > reconnects as expected, in the second one it didn't.
> >
> > I am bit confused here, not sure if this an issue with wpa_supplicant.
> >
> > Can you please help me with the logs to find the root cause?
It looks like the first reconnects is triggered by the event from
wpa_supplicant with scan results.
But in both cases the state machine for the sevices seems to work.
online -> disconnect/failure -> idle. Then the autoconnect code kicks
in. Could it be that in the first case the scan_results trigger the
autoconnect differently then the regular case? Is the service
configured as autoconnect?
Thanks,
Daniel
------------------------------
Date: Fri, 10 Jan 2020 09:54:23 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Connection to WPA fails following connect-failed error
To: Karine Ouellet <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Karine,
Please no top posts and also just plain text emails.
On Thu, Jan 09, 2020 at 04:33:45PM +0000, Karine Ouellet wrote:
> It also seems to me that some states are not cleared. I attached the
> agent logs and also all the logs produced when using connmanctl.
Do you observe this only using connmanctl or do you have some UI which
shows the same problem? I am not sure if connmanctl is able to handle
this correctly. But that said, there is so much going on, I can't
really say what's where things go south.
Thanks,
Daniel
------------------------------
Date: Fri, 10 Jan 2020 11:27:41 +0000
From: Deepu Paul <[email protected]>
Subject: Re: wifi AP disconnect(disconnect reason code 1)
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID:
<cadl1k3nq5tafsevqwtnsb7eg-w0exu4-3avko6rmsn8wo1p...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="0000000000009ef3a3059bc76af8"
--0000000000009ef3a3059bc76af8
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
Yes, auto connect is configured TRUE.
* Type = wifi Security = [ psk ] State = failure Error = blocked
Strength = 73 Favorite = True Immutable = False AutoConnect = True Name
= purpleline*
There are 2 BSSID's 6c:fa:89:55:ce:7a and 58:0a:20:5b:ec:ca for the ssid
"purpleline" (2 access points with the same network )
Not sure that is the problem?
Thanks
Deepu Paul
On Fri, Jan 10, 2020 at 8:40 AM Daniel Wagner <[email protected]> wrote:
> Hi
>
> Please don't top post and also send text emails.
>
> On Thu, Jan 09, 2020 at 04:36:16PM +0000, Deepu Paul wrote:
> > May i know if you a chance to look the logs below please?
>
> Yes.
>
> > > Attaching both connman and wpa_supplicant logs,
> > >
> > > There are 2 disconnects with reason code 1, in the first one it
> > > reconnects as expected, in the second one it didn't.
> > >
> > > I am bit confused here, not sure if this an issue with wpa_supplicant.
> > >
> > > Can you please help me with the logs to find the root cause?
>
> It looks like the first reconnects is triggered by the event from
> wpa_supplicant with scan results.
>
> But in both cases the state machine for the sevices seems to work.
> online -> disconnect/failure -> idle. Then the autoconnect code kicks
> in. Could it be that in the first case the scan_results trigger the
> autoconnect differently then the regular case? Is the service
> configured as autoconnect?
>
> Thanks,
> Daniel
> _______________________________________________
> connman mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--0000000000009ef3a3059bc76af8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Daniel,<div><br></div><div>Yes, auto connect is configu=
red TRUE.</div><div><br></div><div><i>=C2=A0 Type =3D wifi<br>=C2=A0 Securi=
ty =3D [ psk ]<br>=C2=A0 State =3D failure<br>=C2=A0 Error =3D blocked<br>=
=C2=A0 Strength =3D 73<br>=C2=A0 Favorite =3D True<br>=C2=A0 Immutable =3D =
False<br>=C2=A0 AutoConnect =3D True<br>=C2=A0 Name =3D purpleline</i><br><=
/div><div><br></div><div>There are 2=C2=A0 BSSID's 6c:fa:89:55:ce:7a an=
d=C2=A0 58:0a:20:5b:ec:ca for the ssid "purpleline" (2 access poi=
nts with the same network )=C2=A0</div><div><br></div><div>Not sure that is=
the problem?</div><div><br></div><div>Thanks<br></div><div>Deepu Paul</div=
><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Jan 10, 2020 at 8:40 AM Daniel Wagner <<a href=
=3D"mailto:[email protected]";>[email protected]</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Please don't top post and also send text emails.<br>
<br>
On Thu, Jan 09, 2020 at 04:36:16PM +0000, Deepu Paul wrote:<br>
> May i know if you a chance to look the logs below please?<br>
<br>
Yes.<br>
<br>
> > Attaching both connman and wpa_supplicant logs,<br>
> ><br>
> > There are 2=C2=A0 disconnects with reason code 1, in the first on=
e it<br>
> > reconnects as expected, in the second one it didn't.<br>
> ><br>
> > I am bit confused here, not sure if this an issue with wpa_suppli=
cant.<br>
> ><br>
> > Can you please help me with the logs to find the root cause?<br>
<br>
It looks like the first reconnects is triggered by the event from<br>
wpa_supplicant with scan results.<br>
<br>
But in both cases the state machine for the sevices seems to work.<br>
online -> disconnect/failure -> idle. Then the autoconnect code kicks=
<br>
in. Could it be that in the first case the scan_results trigger the<br>
autoconnect differently then the regular case? Is the service<br>
configured as autoconnect?<br>
<br>
Thanks,<br>
Daniel<br>
_______________________________________________<br>
connman mailing list -- <a href=3D"mailto:[email protected]"; target=3D"_=
blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]=
g" target=3D"_blank">[email protected]</a><br>
</blockquote></div>
--0000000000009ef3a3059bc76af8--
------------------------------
Date: Fri, 10 Jan 2020 16:37:01 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v3 0/5] Simplify settings save code
To: Thomas Green <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Thomas,
On Fri, Jan 10, 2020 at 03:33:07PM +0000, Thomas Green wrote:
> Thank you for this. I appreciate all of your work.
Did it help? :)
Thanks,
Daniel
------------------------------
Date: Fri, 10 Jan 2020 16:38:59 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v3 0/5] Simplify settings save code
To: Thomas Green <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Jan 10, 2020 at 03:37:59PM +0000, Thomas Green wrote:
> Yes, it did. Thank you again.
Excellent. In this case I'm going to apply those patches. Uff, solved
finally :)
------------------------------
Date: Fri, 10 Jan 2020 18:04:35 +0200
From: David Llewellyn-Jones <[email protected]>
Subject: [PATCH] vpn-provider: Interpret VPN route ProtocolFamily as
number
To: [email protected]
Cc: David Llewellyn-Jones <[email protected]>
Message-ID: <[email protected]>
The vpnconnection UserRoutes dbus property expects the ProtocolFamily to
be specified, as explained in the documentation:
int ProtocolFamily: Protocol family of the route. Set to 4 if IPv4 and 6
if IPv6 route.
With the current code a GetProperty request will return an integer with
value 4 or 6 as expected. However, when the property is set, it expects
a value of 52 (ASCII char '4') or 54 (ASCII char '6').
This change makes it so that when setting the property, integer values
of 4 or 6 must be used, rather than their ASCII character codes.
---
doc/vpn-connection-api.txt | 4 +++-
vpn/vpn-provider.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/vpn-connection-api.txt b/doc/vpn-connection-api.txt
index cb5de69b..ec557889 100644
--- a/doc/vpn-connection-api.txt
+++ b/doc/vpn-connection-api.txt
@@ -185,7 +185,9 @@ Properties string State [readonly]
int ProtocolFamily
Protocol family of the route. Set to 4
- if IPv4 and 6 if IPv6 route.
+ if IPv4 and 6 if IPv6 route. Set to 0
+ (PF_UNSPEC) or omit, to have it assigned
+ automatically.
string Network
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index d93f5b47..1d5d734d 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -295,10 +295,10 @@ static GSList *read_route_dict(GSList *routes,
DBusMessageIter *dicts)
}
} else {
switch (family) {
- case '4':
+ case 4:
family = AF_INET;
break;
- case '6':
+ case 6:
family = AF_INET6;
break;
default:
--
2.17.1
------------------------------
Date: Fri, 10 Jan 2020 17:20:36 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v3 0/5] Simplify settings save code
To: [email protected]
Cc: Thomas Green <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Thu, Jan 09, 2020 at 09:24:06AM +0100, Daniel Wagner wrote:
> This should finally fix the empty gateway issue reported by Thomas.
All patches applied.
------------------------------
Date: Fri, 10 Jan 2020 17:26:14 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] vpn-provider: Interpret VPN route ProtocolFamily
as number
To: David Llewellyn-Jones <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Jan 10, 2020 at 06:04:35PM +0200, David Llewellyn-Jones wrote:
> The vpnconnection UserRoutes dbus property expects the ProtocolFamily to
> be specified, as explained in the documentation:
>
> int ProtocolFamily: Protocol family of the route. Set to 4 if IPv4 and 6
> if IPv6 route.
>
> With the current code a GetProperty request will return an integer with
> value 4 or 6 as expected. However, when the property is set, it expects
> a value of 52 (ASCII char '4') or 54 (ASCII char '6').
Uhh, that is indeed not nice.
> This change makes it so that when setting the property, integer values
> of 4 or 6 must be used, rather than their ASCII character codes.
I've left the '4' and '6' in the switch because no need to break
existing user base.
Patch applied.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 14
***************************************
