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] vpn-provider: Implement setting of multiple VPN
properties with one call
(Daniel Wagner)
2. Re: [PATCH 1/3] vpn-provider: Save configuration only when a property
value is changed
(Daniel Wagner)
3. Re: wifi AP disconnect(disconnect reason code 1) (Daniel Wagner)
4. Re: wifi AP disconnect(disconnect reason code 1) (Deepu Paul)
----------------------------------------------------------------------
Date: Wed, 18 Dec 2019 10:39:08 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 2/3] 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=us-ascii
Hi Jussi,
On Tue, Dec 10, 2019 at 04:08:11PM +0200, Jussi Laakkonen wrote:
> Add SetProperties D-Bus method (set_properties()) to allow setting all
> VPN properties with one D-Bus call. This improves the performance when
> multiple (or all) properties are to be changed but reduces the
> granularity of errors reported back to the caller. Properties are
> accepted in the same format as with GetProperties D-Bus method sends
> them, a{sv}. Empty strings as property values, or empty array for
> UserRoutes will clear the property value.
I was pondering on this proposal for a while. I am just not convience
to introduce a SetProperties method is a good idea. We don't have
this kind of API in any other daemon and also we might eventually like
to move (connman v2) to the freedesktop verion of the properties
interface:
https://dbus.freedesktop.org/doc/dbus-java/api/org/freedesktop/DBus.Properties.html
So one way you could do push this one level down behind SetProperty
and do a parsing of a config set there. It's almost the same just
avoid to do introduce a D-Bus API.
> If there is at least one invalid property, then InvalidProperty D-Bus
> error is sent as reply. Invalid properties > immutable properties in
> case of error, there can be permission errors caused by immutable
> properties when InvalidProperty error is sent. Only when there are only
> permission errors then PermissionDenied D-Bus error is sent. In both
> cases the D-Bus error message is amended with the property names that
> caused the errors.
>
> Move setting of a single property into its own function, usable by both
> set_property() and set_properties(). The set_vpn_property() retains the
> functionality by changing either the routes or a single string value,
> returns 0 when success, -EALREADY when there is no change on property
> value and appropriate error (-EINVAL/-EPERM/-ENOMEM) otherwise.
> ---
> vpn/vpn-provider.c | 208 ++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 176 insertions(+), 32 deletions(-)
>
> diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
> index bf102536..b01da31d 100644
> --- a/vpn/vpn-provider.c
> +++ b/vpn/vpn-provider.c
> @@ -472,6 +472,177 @@ static bool compare_network_lists(GSList *a, GSList *b)
> return true;
> }
>
> +static int set_provider_property(struct vpn_provider *provider,
> + const char *name, DBusMessageIter *value, int type,
> + bool clear_if_empty)
> +{
> + int err = 0;
> +
> + DBG("provider %p", provider);
> +
> + if (!provider || !name || !value)
> + return -EINVAL;
> +
> + if (g_str_equal(name, "UserRoutes")) {
> + GSList *networks;
> +
> + if (type != DBUS_TYPE_ARRAY)
> + return -EINVAL;
> +
> + networks = get_user_networks(value);
> + if (!networks && !clear_if_empty)
> + return -EINVAL;
> +
> + if (compare_network_lists(provider->user_networks, networks)) {
> + g_slist_free_full(networks, free_route);
> + return -EALREADY;
> + }
> +
> + del_routes(provider);
> + provider->user_networks = networks;
> + set_user_networks(provider, provider->user_networks);
> +
> + if (!handle_routes)
> + send_routes(provider, provider->user_routes,
> + "UserRoutes");
> + } else {
> + const char *str;
> +
> + if (type != DBUS_TYPE_STRING)
> + return -EINVAL;
> +
> + dbus_message_iter_get_basic(value, &str);
> +
> + DBG("property %s value %s", name, str);
> +
> + /*
> + * Empty strings must not be allowed unless explicitely set to
> + * be cleared if the string is empty. If the value is to be
> + * cleared ClearProperty D-Bus method must be used.
> + */
> + if (!*str && !clear_if_empty)
> + return -EINVAL;
> +
> + err = vpn_provider_set_string(provider, name,
> + *str ? str : NULL);
> + }
> +
> + return err;
> +}
> +
> +static GString *append_to_gstring(GString *str, const char *value)
> +{
> + if (!str)
> + return g_string_new(value);
> +
> + g_string_append_printf(str, ",%s", value);
> +
> + return str;
> +}
> +
> +static DBusMessage *set_properties(DBusConnection *conn, DBusMessage *msg,
> + void *data)
> +{
> + struct vpn_provider *provider = data;
> + DBusMessageIter iter, dict;
> + const char *key;
> + bool change = false;
> + GString *invalid = NULL;
> + GString *denied = NULL;
> + int type;
> + int err;
> +
> + DBG("conn %p", conn);
> +
> + if (provider->immutable)
> + return __connman_error_not_supported(msg);
> +
> + if (!dbus_message_iter_init(msg, &iter))
> + return __connman_error_invalid_arguments(msg);
> +
> + for (dbus_message_iter_recurse(&iter, &dict);
> + dbus_message_iter_get_arg_type(&dict) ==
> + DBUS_TYPE_DICT_ENTRY;
> + dbus_message_iter_next(&dict)) {
> + DBusMessageIter entry, value;
> +
> + dbus_message_iter_recurse(&dict, &entry);
> + /*
> + * Ignore invalid types in order to process all values in the
> + * dict. If there is an invalid type in between the dict there
> + * may already be changes on some values and breaking out here
> + * would have the provider in an inconsistent state, leaving
> + * the rest, potentially correct property values untouched.
> + */
> + if (dbus_message_iter_get_arg_type(&entry) != DBUS_TYPE_STRING)
> + continue;
> +
> + dbus_message_iter_get_basic(&entry, &key);
> +
> + DBG("key %s", key);
> +
> + dbus_message_iter_next(&entry);
> + /* Ignore and report back all non variant types. */
> + if (dbus_message_iter_get_arg_type(&entry)
> + != DBUS_TYPE_VARIANT) {
> + invalid = append_to_gstring(invalid, key);
> + continue;
> + }
> +
> + dbus_message_iter_recurse(&entry, &value);
> +
> + type = dbus_message_iter_get_arg_type(&value);
> + /* Ignore and report back all invalid property types */
> + if (type != DBUS_TYPE_STRING && type != DBUS_TYPE_ARRAY) {
> + invalid = append_to_gstring(invalid, key);
> + continue;
> + }
> +
> + err = set_provider_property(provider, key, &value, type, true);
> + switch (err) {
> + case 0:
> + change = true;
> + break;
> + case -EINVAL:
> + invalid = append_to_gstring(invalid, key);
> + break;
> + case -EPERM:
> + denied = append_to_gstring(denied, key);
> + break;
> + }
> + }
> +
> + if (change)
> + vpn_provider_save(provider);
Don't you also need to set all vpn_provider_set_string() back? This
just avoids to store the current configuration but the configuration
is still there. Unless I err again...
> +
> + if (invalid || denied) {
> + DBusMessage *error;
> + char *invalid_str = g_string_free(invalid, FALSE);
> + char *denied_str = g_string_free(denied, FALSE);
> +
> + /*
> + * If there are both invalid and denied properties report
> + * back invalid arguments. Add also the failed properties to
> + * the error message.
> + */
> + error = g_dbus_create_error(msg, (invalid ?
> + CONNMAN_ERROR_INTERFACE ".InvalidProperty" :
> + CONNMAN_ERROR_INTERFACE ".PermissionDenied"),
> + "%s %s%s%s", (invalid ? "Invalid properties" :
> + "Permission denied"),
> + (invalid ? invalid_str : ""),
> + (invalid && denied ? "," : ""),
> + (denied ? denied_str : ""));
> +
> + g_free(invalid_str);
> + g_free(denied_str);
> +
> + return error;
> + }
> +
> + return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
> +}
> +
> static DBusMessage *set_property(DBusConnection *conn, DBusMessage *msg,
> void *data)
> {
> @@ -479,7 +650,7 @@ static DBusMessage *set_property(DBusConnection *conn,
> DBusMessage *msg,
> DBusMessageIter iter, value;
> const char *name;
> int type;
> - int err = 0;
> + int err;
>
> DBG("conn %p", conn);
>
> @@ -502,37 +673,7 @@ static DBusMessage *set_property(DBusConnection *conn,
> DBusMessage *msg,
>
> type = dbus_message_iter_get_arg_type(&value);
>
> - if (g_str_equal(name, "UserRoutes")) {
> - GSList *networks;
> -
> - if (type != DBUS_TYPE_ARRAY)
> - return __connman_error_invalid_arguments(msg);
> -
> - networks = get_user_networks(&value);
> - if (!networks)
> - return __connman_error_invalid_arguments(msg);
> -
> - if (compare_network_lists(provider->user_networks, networks))
> - return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
> -
> - del_routes(provider);
> - provider->user_networks = networks;
> - set_user_networks(provider, provider->user_networks);
> -
> - if (!handle_routes)
> - send_routes(provider, provider->user_routes,
> - "UserRoutes");
> - } else {
> - const char *str;
> -
> - if (type != DBUS_TYPE_STRING)
> - return __connman_error_invalid_arguments(msg);
> -
> - dbus_message_iter_get_basic(&value, &str);
> -
> - err = vpn_provider_set_string(provider, name, str);
> - }
> -
> + err = set_provider_property(provider, name, &value, type, false);
> switch (err) {
> case 0:
> vpn_provider_save(provider);
> @@ -640,6 +781,9 @@ static const GDBusMethodTable connection_methods[] = {
> { GDBUS_METHOD("GetProperties",
> NULL, GDBUS_ARGS({ "properties", "a{sv}" }),
> get_properties) },
> + { GDBUS_METHOD("SetProperties",
> + GDBUS_ARGS({ "properties", "a{sv}" }),
> + NULL, set_properties) },
> { GDBUS_METHOD("SetProperty",
> GDBUS_ARGS({ "name", "s" }, { "value", "v" }),
> NULL, set_property) },
> --
> 2.20.1
> _______________________________________________
> connman mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
Thanks,
Daniel
------------------------------
Date: Wed, 18 Dec 2019 10:39:28 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 1/3] vpn-provider: Save configuration only when a
property value is changed
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Tue, Dec 10, 2019 at 04:08:10PM +0200, Jussi Laakkonen wrote:
> This change improves the saving of the VPN provider values to disk
> immediately after the value has been changed on a property. To avoid
> unnecessary writes to disk the changes are not written when a property
> change, or clearing a property, does not introduce a change to its
> value. Thus, PropertyChanged signal is emitted only when the property
> value has been changed.
>
> With any other than UserRoutes property simple value comparison is done.
> If the UserRoutes are changed these are read from D-Bus message into
> sorted list that is compared against the sorted list of saved
> UserRoutes. Having the lists sorted will increase performance when
> comparing them, especially if the lists are long. For this a
> compare_route() is implemented to support sorting the rules by 1) IP
> protocol type, 2) network addresses, 3) netmask addresses and 4) gateway
> addresses.
>
> The set_string() is amended to return -EALREADY when there is no change
> in the property value. In case the property value is changed 0 is
> returned. Handling of the return value is added to set_property() and
> clear_property() functions registered to VPN provider D-Bus interface.
> In both of these writing the changes to disk depends on the success of
> the change. Both, set_property() and clear_property() functions now
> return also PermissionDenied as error if immutable property is attempted
> to be changed.
>
> This change has the effect of not reseting errors and not setting the
> VPN provider to idle if it is in error state when a single property is
> attempted to saved without change, or an immutable value is attempted
> to be cleared. In order to have the state changed and errors cleared, a
> property value has to be changed.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Wed, 18 Dec 2019 10:46: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,
On Fri, Dec 13, 2019 at 06:18:20PM +0000, Deepu Paul wrote:
> Hello,
>
> I am connected to a wifi AP, in every few minutes(around 30 minutes) i get
> a disconnect call back
> (wifi.c, disconnect_reasoncode method)
> with reason code 1, but for first few attempts it reconnects automatically
> to the same AP(just have that n/w as the favorite). It fails to connect
> after few successful reconnects.
>
> When i check the logs it is trying to do auto scan but not able to
> authenticate with the n/w.
>
> For all the successful reconnect i get the below logs but this is missing
> for the failure scenario.
> wpa_supplicant[560]: wlansta0: SME: Trying to authenticate with
> 58:0a:20:5b:ec:ca (SSID='purpleline' freq=5220 MHz)
> wpa_supplicant[560]: wlansta0: Trying to associate with 58:0a:20:5b:ec:ca
> (SSID='purpleline' freq=5220 MHz)
That is what I would expect. wpa_supplicant should handle the reauth, IIRC,
> Found this issue with a Cisco router, seems they is re auth every few
> minute for this router.
> Can you please help me with this?
>
> I think i may need to add some conditional checks in
> static void interface_state(GSupplicantInterface *interface)
> {
> switch (wifi->disconnect_code) {
> case 1: /* Unspecified reason */
>
> }
I think I know what you want to do. If you get a disconnect just try
to reconnect. This might not be correct, e.g. what if your credentials
have changed and you try the old ones again and again. Some networks
will then disable your account.
The question is what happens if the reauth handled by wpa_supplicant
goes wrong.
Thanks,
Daniel
------------------------------
Date: Wed, 18 Dec 2019 12:54:14 +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:
<CADL1K3kXrLySEMqH=zzCet+zP+FFfYA9ftUmaHuHueWo==7...@mail.gmail.com>
Content-Type: multipart/mixed; boundary="000000000000c824470599f9f1c2"
--000000000000c824470599f9f1c2
Content-Type: multipart/alternative; boundary="000000000000c824450599f9f1c0"
--000000000000c824450599f9f1c0
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
Thank you for the answer.
I am able to fix the issue with the attached patch.
I have my board with connman service running for 2-3 days now and still
that AP is connected with the patch fix(from the logs i can see it
disconnected more than 50 times, but successfully reconnected by the auto
scan).
connmanctl> services
*AO purpleline
wifi_7804731c31f0_707572706c656c696e65_managed_psk
Can you please review the patch?
In the wifi.c, this is done in the interface_state
case G_SUPPLICANT_STATE_DISCONNECTED:
if (network != wifi->pending_network) {
connman_network_set_connected(network, false);
connman_network_set_associating(network, false);
}
but in my case when it disconnect with reason code 1, it enters in this
state only like 90% of the times. That's why i am forcing connman network
connected flag to false in the disconnect callback.
Please let me know for more information's.
Thanks
Deepu Paul
On Wed, Dec 18, 2019 at 9:46 AM Daniel Wagner <[email protected]> wrote:
> Hi,
>
> On Fri, Dec 13, 2019 at 06:18:20PM +0000, Deepu Paul wrote:
> > Hello,
> >
> > I am connected to a wifi AP, in every few minutes(around 30 minutes) i
> get
> > a disconnect call back
> > (wifi.c, disconnect_reasoncode method)
> > with reason code 1, but for first few attempts it reconnects
> automatically
> > to the same AP(just have that n/w as the favorite). It fails to connect
> > after few successful reconnects.
> >
> > When i check the logs it is trying to do auto scan but not able to
> > authenticate with the n/w.
> >
> > For all the successful reconnect i get the below logs but this is missing
> > for the failure scenario.
> > wpa_supplicant[560]: wlansta0: SME: Trying to authenticate with
> > 58:0a:20:5b:ec:ca (SSID='purpleline' freq=5220 MHz)
> > wpa_supplicant[560]: wlansta0: Trying to associate with 58:0a:20:5b:ec:ca
> > (SSID='purpleline' freq=5220 MHz)
>
> That is what I would expect. wpa_supplicant should handle the reauth, IIRC,
>
> > Found this issue with a Cisco router, seems they is re auth every few
> > minute for this router.
> > Can you please help me with this?
> >
> > I think i may need to add some conditional checks in
> > static void interface_state(GSupplicantInterface *interface)
> > {
> > switch (wifi->disconnect_code) {
> > case 1: /* Unspecified reason */
> >
> > }
>
> I think I know what you want to do. If you get a disconnect just try
> to reconnect. This might not be correct, e.g. what if your credentials
> have changed and you try the old ones again and again. Some networks
> will then disable your account.
>
> The question is what happens if the reauth handled by wpa_supplicant
> goes wrong.
>
> Thanks,
> Daniel
> _______________________________________________
> connman mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--000000000000c824450599f9f1c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Daniel,<div><br></div><div>Thank you for the answer.</d=
iv><div><br></div><div>I am able to fix the issue=C2=A0with the attached pa=
tch.</div><div><br></div><div>I have my board with connman service running =
for 2-3 days now and still that AP is connected with the patch fix(from the=
logs i can see it</div><div>disconnected more than 50 times, but successfu=
lly reconnected by the auto scan).</div><div>=C2=A0 =C2=A0connmanctl> se=
rvices</div><div>=C2=A0 =C2=A0 *AO purpleline =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 wifi_7804731c31f0_707572706c656c696e65_managed_psk<br></div><div><br=
></div><div>Can you please review the patch?</div><div><br></div><div>In th=
e wifi.c, this is done in the interface_state</div><div>case G_SUPPLICANT_S=
TATE_DISCONNECTED:<br></div><div>=C2=A0 =C2=A0 =C2=A0if (network !=3D wifi-=
>pending_network) {</div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connman_netw=
ork_set_connected(network, false);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 co=
nnman_network_set_associating(network, false);<br>=C2=A0 =C2=A0 =C2=A0}<div=
><br></div><div>but in my case when it disconnect with reason code 1, it en=
ters in this state only like 90% of the times. That's why i am forcing=
=C2=A0 connman network connected flag to false in the disconnect callback.<=
/div><div><br></div><div><br></div><div>Please let me know for more informa=
tion's.</div><div><br></div><div>Thanks</div><div>Deepu Paul=C2=A0</div=
><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Dec 18, 2019 at 9:46 AM Daniel Wagne=
r <<a href=3D"mailto:[email protected]";>[email protected]</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Fri, Dec 13, 2019 at 06:18:20PM +0000, Deepu Paul wrote:<br>
> Hello,<br>
> <br>
> I am connected to a wifi AP, in every few minutes(around 30 minutes) i=
get<br>
> a disconnect call back<br>
> (wifi.c, disconnect_reasoncode method)<br>
> with reason code 1, but for first few attempts it reconnects automatic=
ally<br>
> to the same AP(just have that n/w as the favorite). It fails to connec=
t<br>
> after few successful reconnects.<br>
> <br>
> When i check the logs it is trying to do auto scan but not able to<br>
> authenticate with the n/w.<br>
> <br>
> For all the successful reconnect i get the below logs but this is miss=
ing<br>
> for the failure scenario.<br>
> wpa_supplicant[560]: wlansta0: SME: Trying to authenticate with<br>
> 58:0a:20:5b:ec:ca (SSID=3D'purpleline' freq=3D5220 MHz)<br>
> wpa_supplicant[560]: wlansta0: Trying to associate with 58:0a:20:5b:ec=
:ca<br>
> (SSID=3D'purpleline' freq=3D5220 MHz)<br>
<br>
That is what I would expect. wpa_supplicant should handle the reauth, IIRC,=
<br>
<br>
> Found this issue with a Cisco router, seems they is re auth every few<=
br>
> minute for this router.<br>
> Can you please help me with this?<br>
> <br>
> I think i may need to add some conditional checks in<br>
> static void interface_state(GSupplicantInterface *interface)<br>
> {<br>
> switch (wifi->disconnect_code) {<br>
> case 1: /* Unspecified reason */<br>
> <br>
> }<br>
<br>
I think I know what you want to do. If you get a disconnect just try<br>
to reconnect. This might not be correct, e.g. what if your credentials<br>
have changed and you try the old ones again and again. Some networks<br>
will then disable your account.<br>
<br>
The question is what happens if the reauth handled by wpa_supplicant<br>
goes wrong.<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>
--000000000000c824450599f9f1c0--
--000000000000c824470599f9f1c2
Content-Type: text/x-patch; charset="US-ASCII";
name="0001-wifi.c-AP-disconnects-with-reason-code-1-and-fails-t.patch"
Content-Disposition: attachment;
filename="0001-wifi.c-AP-disconnects-with-reason-code-1-and-fails-t.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_k4baqdu70>
X-Attachment-Id: f_k4baqdu70
RnJvbSBlODkwOTkzMzczODRkNGQ0NzgxYTRhODRlNGM2MjZlNWRlY2I3YmU0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBEZWVwdSBQYXVsIDxkZWVwdS5wYXVsQGpjaS5jb20+CkRhdGU6
IFRodSwgMTIgRGVjIDIwMTkgMDk6MDY6MTMgKzAwMDAKU3ViamVjdDogW1BBVENIXSB3aWZpLmM6
IEFQIGRpc2Nvbm5lY3RzIHdpdGggcmVhc29uIGNvZGUgMSBhbmQgZmFpbHMgdG8KIHJlY29ubmVj
dC4KCm9uZSBvZiB0aGUgcm91dGVyIGRpc2Nvbm5lY3RzIHdpdGggcmVhc29uIGNvZGUgMSwgaXQg
Z2V0cyByZWNvbm5lY3RlZAphdXRvbWF0aWNhbGx5IGZvciBmZXcgdGltZXMgYW5kIGZhaWxzIGlu
IHRoZSBzdWNjZXNzaXZlIGF0dGVtcHRzLgotLS0KIHBsdWdpbnMvd2lmaS5jIHwgNiArKysrKysK
IDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9wbHVnaW5zL3dp
ZmkuYyBiL3BsdWdpbnMvd2lmaS5jCmluZGV4IGY4YzIyYmUuLmQ4NjE5NzQgMTAwNjQ0Ci0tLSBh
L3BsdWdpbnMvd2lmaS5jCisrKyBiL3BsdWdpbnMvd2lmaS5jCkBAIC0zMjA0LDYgKzMyMDQsMTIg
QEAgc3RhdGljIHZvaWQgZGlzY29ubmVjdF9yZWFzb25jb2RlKEdTdXBwbGljYW50SW50ZXJmYWNl
ICppbnRlcmZhY2UsCiAKIAlpZiAod2lmaSAhPSBOVUxMKSB7CiAJCXdpZmktPmRpc2Nvbm5lY3Rf
Y29kZSA9IHJlYXNvbmNvZGU7CisKKwkJaWYoYWJzKHJlYXNvbmNvZGUpID09IDEpCisJCXsKKwkJ
CWNvbm5tYW5faW5mbygiV2lmaSBkaXNjb25uZWN0ZWQgd2l0aCBSZWFzb24gQ29kZSAxIik7CisJ
CQljb25ubWFuX25ldHdvcmtfc2V0X2Nvbm5lY3RlZCh3aWZpLT5uZXR3b3JrLCBmYWxzZSk7CisJ
CX0KIAl9CiB9CiAKLS0gCjIuMjAuMQoK
--000000000000c824470599f9f1c2--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 50, Issue 7
**************************************
