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 0/2] Remove GDateTime API usage (Daniel Wagner)
2. [PATCH 2/2] tools: Remove GDateTime API usage (Daniel Wagner)
3. [PATCH 1/2] service: Remove GDateTime API usage (Daniel Wagner)
4. Re: [PATCH v2] l2tp: Add default value for 'ipsec saref' to be able to
use 'lock' with pppd
([email protected])
5. [PATCH] l2tp: Unset password as hidden value to avoid property changed
signal
(Jussi Laakkonen)
6. Re: [PATCH] l2tp: Unset password as hidden value to avoid property
changed signal
(Daniel Wagner)
7. Re: [RFC 1/2] Storage based service retrieval
(Ryll, Jan (GED-SDD2))
----------------------------------------------------------------------
Date: Fri, 8 Nov 2019 09:15:21 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 0/2] Remove GDateTime API usage
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
As it turns out, the GDateTime was introduced in 2.26 but not the
iso8601 function.
Daniel Wagner (2):
service: Remove GDateTime API usage
tools: Remove GDateTime API usage
src/service.c | 31 +++++++++++++------------------
tools/stats-tool.c | 13 +++----------
2 files changed, 16 insertions(+), 28 deletions(-)
--
2.23.0
------------------------------
Date: Fri, 8 Nov 2019 09:15:23 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 2/2] tools: Remove GDateTime API usage
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
The g_date_time_new_from_iso8601() was introduced with GLib v2.56. We
don't want to update our version dependency. So let's use good old
POSIX APIs instead.
---
tools/stats-tool.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/tools/stats-tool.c b/tools/stats-tool.c
index 193eed24565f..105dc4973edb 100644
--- a/tools/stats-tool.c
+++ b/tools/stats-tool.c
@@ -108,18 +108,11 @@ static char *option_last_file_name = NULL;
static bool parse_start_ts(const char *key, const char *value,
gpointer user_data, GError **error)
{
- GTimeZone *tz;
- GDateTime *dt;
+ struct tm tm;
- tz = g_time_zone_new_local();
- dt = g_date_time_new_from_iso8601(value, tz);
- g_time_zone_unref(tz);
- if (!dt)
- return false;
+ strptime(value, "%FT%TZ", &tm);
+ option_start_ts = mktime(&tm);
- option_start_ts = g_date_time_get_second(dt);
-
- g_date_time_unref(dt);
return true;
}
--
2.23.0
------------------------------
Date: Fri, 8 Nov 2019 09:15:22 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH 1/2] service: Remove GDateTime API usage
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
The g_date_time_new_from_iso8601() was introduced with GLib v2.56. We
don't want to update our version dependency. So let's use good old
POSIX APIs instead.
---
src/service.c | 31 +++++++++++++------------------
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/src/service.c b/src/service.c
index 7e1446b7cf3b..bf6dcb600c1e 100644
--- a/src/service.c
+++ b/src/service.c
@@ -84,7 +84,7 @@ struct connman_service {
bool hidden;
bool ignore;
bool autoconnect;
- GDateTime *modified;
+ struct tm modified;
unsigned int order;
char *name;
char *passphrase;
@@ -380,27 +380,25 @@ static void set_split_routing(struct connman_service
*service, bool value)
static void update_modified(struct connman_service *service)
{
- GTimeZone *tz;
+ time_t now;
- if (service->modified)
- g_date_time_unref(service->modified);
-
- tz = g_time_zone_new_local();
- service->modified = g_date_time_new_now(tz);
- g_time_zone_unref(tz);
+ time(&now);
+ gmtime_r(&now, &service->modified);
}
static void update_modified_from_iso8601(struct connman_service *service,
char *str)
{
- GTimeZone *tz;
+ strptime(str, "%FT%TZ", &service->modified);
+}
- if (service->modified)
- g_date_time_unref(service->modified);
+static char *get_modified_format_iso8601(struct connman_service *service)
+{
+ char buf[255];
- tz = g_time_zone_new_local();
- service->modified = g_date_time_new_from_iso8601(str, tz);
- g_time_zone_unref(tz);
+ strftime(buf, sizeof(buf), "%FT%TZ", &service->modified);
+
+ return g_strdup(buf);
}
int __connman_service_load_modifiable(struct connman_service *service)
@@ -728,7 +726,7 @@ static int service_save(struct connman_service *service)
break;
}
- str = g_date_time_format_iso8601(service->modified);
+ str = get_modified_format_iso8601(service);
if (str) {
g_key_file_set_string(keyfile, service->identifier,
"Modified", str);
@@ -5086,9 +5084,6 @@ static void service_free(gpointer user_data)
g_free(service->config_file);
g_free(service->config_entry);
- if (service->modified)
- g_date_time_unref(service->modified);
-
if (service->stats.timer)
g_timer_destroy(service->stats.timer);
if (service->stats_roaming.timer)
--
2.23.0
------------------------------
Date: Fri, 08 Nov 2019 08:40:36 -0000
From: [email protected]
Subject: Re: [PATCH v2] l2tp: Add default value for 'ipsec saref' to
be able to use 'lock' with pppd
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
base64? Ok, sorry, that was not intended. Not sure what caused that, nothing
changed at my end, except I think I had to use different email server for
sending this patch. Please let me know if this keeps happening.
------------------------------
Date: Fri, 8 Nov 2019 11:10:15 +0200
From: Jussi Laakkonen <[email protected]>
Subject: [PATCH] l2tp: Unset password as hidden value to avoid
property changed signal
To: [email protected]
Message-ID: <[email protected]>
If a password is unset with vpn_provider_set_string() a property change
signal will be sent (see vpn/vpn-provider.c:set_string()). This should
be avoided because a VPN agent listening for changes may interpret this
as changing the password into empty string.
This would be the case when authentication fails or when disconnecting.
At the next connection attempt the password retrieved via VPN agent
would be an empty string. Added empty string checks to make sure this
never happens and password is requested from VPN agent when it is also
an empty string.
---
vpn/plugins/l2tp.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/vpn/plugins/l2tp.c b/vpn/plugins/l2tp.c
index efe80863..48894aa5 100644
--- a/vpn/plugins/l2tp.c
+++ b/vpn/plugins/l2tp.c
@@ -179,7 +179,8 @@ static int l2tp_notify(DBusMessage *msg, struct
vpn_provider *provider)
DBG("authentication failure");
vpn_provider_set_string(provider, "L2TP.User", NULL);
- vpn_provider_set_string(provider, "L2TP.Password", NULL);
+ vpn_provider_set_string_hide_value(provider, "L2TP.Password",
+ NULL);
return VPN_STATE_AUTH_FAILURE;
}
@@ -652,7 +653,7 @@ static int run_connect(struct vpn_provider *provider,
int l2tp_fd, pppd_fd;
int err;
- if (!username || !password) {
+ if (!username || !*username || !password || !*password) {
DBG("Cannot connect username %s password %p",
username, password);
err = -EINVAL;
@@ -723,7 +724,7 @@ static void request_input_cb(struct vpn_provider *provider,
{
struct l2tp_private_data *data = user_data;
- if (!username || !password)
+ if (!username || !*username || !password || !*password)
DBG("Requesting username %s or password failed, error %s",
username, error);
else if (error)
@@ -758,7 +759,7 @@ static int l2tp_connect(struct vpn_provider *provider,
DBG("user %s password %p", username, password);
- if (!username || !password) {
+ if (!username || !*username || !password || !*password) {
struct l2tp_private_data *data;
data = g_try_new0(struct l2tp_private_data, 1);
@@ -805,7 +806,7 @@ static void l2tp_disconnect(struct vpn_provider *provider)
if (!provider)
return;
- vpn_provider_set_string(provider, "L2TP.Password", NULL);
+ vpn_provider_set_string_hide_value(provider, "L2TP.Password", NULL);
connman_agent_cancel(provider);
}
--
2.20.1
------------------------------
Date: Fri, 8 Nov 2019 11:22:06 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] l2tp: Unset password as hidden value to avoid
property changed signal
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Nov 08, 2019 at 11:10:15AM +0200, Jussi Laakkonen wrote:
> If a password is unset with vpn_provider_set_string() a property change
> signal will be sent (see vpn/vpn-provider.c:set_string()). This should
> be avoided because a VPN agent listening for changes may interpret this
> as changing the password into empty string.
>
> This would be the case when authentication fails or when disconnecting.
> At the next connection attempt the password retrieved via VPN agent
> would be an empty string. Added empty string checks to make sure this
> never happens and password is requested from VPN agent when it is also
> an empty string.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Fri, 8 Nov 2019 14:00:32 +0000
From: "Ryll, Jan (GED-SDD2)" <[email protected]>
Subject: Re: [RFC 1/2] Storage based service retrieval
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: multipart/alternative;
boundary="_000_a5b5f644d83741fb9a13bba373a9d6fbbshgcom_"
--_000_a5b5f644d83741fb9a13bba373a9d6fbbshgcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
this RFC seems to fit to my question "what if a wifi network service is not=
available anymore and I need to remove/clear the credential / Passphrase? =
How could I achieve this?".
So I read the comments and agree with Patrik. The GetKnownServices() method=
should return also the currently unavailable/absent networks for which a s=
ervice folder exists.
In my case there are many service folders like
/var/lib/connman/wifi_38b4d3ffe973_4c4544455f48435f32383434_managed_psk
/var/lib/connman/wifi_38b4d3ffe973_4c45765455f484366f323758_managed_psk
...
This folders should be also removable after the change with the service rem=
ove functionality.
Could this be a solution?
Best regards
Jan
--_000_a5b5f644d83741fb9a13bba373a9d6fbbshgcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"; xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Nur Text Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.NurTextZchn
{mso-style-name:"Nur Text Zchn";
mso-style-priority:99;
mso-style-link:"Nur Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">this RFC seems to fit to my =
question “what if a wifi network service is not available anymore and=
I need to remove/clear the credential / Passphrase? How could I achieve th=
is?”.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">So I read the comments and a=
gree with Patrik. The GetKnownServices() method should return also the curr=
ently unavailable/absent networks for which a service folder exists.<o:p></=
o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">In my case there are many se=
rvice folders like<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">/var/lib/connman/wifi_38b4d3=
ffe973_4c4544455f48435f32383434_managed_psk<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">/var/lib/connman/wifi_38b4d3=
ffe973_4c45765455f484366f323758_managed_psk<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">…<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This folders should be also rem=
ovable after the change with the service remove functionality.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Could this be a solution?<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Best regards<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Jan<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
</div>
</body>
</html>
--_000_a5b5f644d83741fb9a13bba373a9d6fbbshgcom_--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 49, Issue 8
**************************************
