Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 4/4] wps: add new WPS API for technology
(Daniel Wagner)
2. Re: [PATCH] build: Remove multiply defined backtrace_sources
(Daniel Wagner)
3. Re: [PATCH] vpn: Reset flags before calling vpn_newlink() if
VPN interface was up (Daniel Wagner)
4. Re: [PATCH] vpn: Add remove function callback to VPN driver
(Daniel Wagner)
5. Re: [PATCH] vpn: Fix memory leak (Daniel Wagner)
6. Re: [PATCH] vpn: Add remove function callback to VPN driver
(Jussi Laakkonen)
7. Re: [PATCH 0/4] VPN tweaks (Daniel Wagner)
8. Re: [PATCH] vpn: Add remove function callback to VPN driver
(Daniel Wagner)
9. [PATCH] vpn: Save provider configuration when properties are
changed (Jussi Laakkonen)
----------------------------------------------------------------------
Message: 1
Date: Thu, 27 Sep 2018 08:41:44 +0200
From: Daniel Wagner <w...@monom.org>
To: Slava Monich <slava.mon...@jolla.com>, connman@lists.01.org,
"Holtmann, Marcel" <marcel.holtm...@intel.com>
Subject: Re: [PATCH 4/4] wps: add new WPS API for technology
Message-ID: <9bb593fc-6526-32e6-5d59-2d3cfc760...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
>> To avoid throwing technology specific things together into one monstrous
>> interface (union instead of intersection), an ofono-style approach can
>> be used. ofono Modem has "Interfaces" property which is a list of other
>> interfaces that modem supports. connman Technology can have one too.
>> Wifi Technology would support additional WPS interface and other kinds
>> of Technology won't. That would make sense to me.
>
> So with 'Interfaces' in the Technology API we introduce a device
> interface. I don't mind going in this direction. Especially since oFono
> has the same pattern for this.
Anyone willing to work on this idea? I think it really makes sense to
introduce the 'interface' property for devices. We have a bunch of use
cases which are hard to support (two wifi cards) with the current APIs.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 27 Sep 2018 08:47:02 +0200
From: Daniel Wagner <w...@monom.org>
To: Slava Monich <slava.mon...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH] build: Remove multiply defined backtrace_sources
Message-ID: <257574f1-2b50-06a6-f4b4-ba71fd926...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Slava,
On 09/18/2018 10:53 AM, Slava Monich wrote:
> Makefile.am:58: warning: backtrace_sources multiply defined in condition
> BACKTRACE ...
> Makefile.am:37: ... 'backtrace_sources' previously defined here
Patch applied.
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 27 Sep 2018 08:48:36 +0200
From: Daniel Wagner <w...@monom.org>
To: Jussi Laakkonen <jussi.laakko...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH] vpn: Reset flags before calling vpn_newlink() if
VPN interface was up
Message-ID: <ff330122-5e9b-4ee0-5e87-70c7521b1...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 09/25/2018 03:53 PM, Jussi Laakkonen wrote:
> This fixes the issue of VPN provider not being set ready as VPN
> interface was already up when vpn_notify() was called. It is required to
> reset the flags before calling vpn_newlink(), otherwise the state of the
> VPN provider is not changed.
>
> This would result in a situation where VPN provider settings were not
> sent to connmand and later adding the routes of a VPN will fail as the
> interface index was not updated. Also other information (interface type,
> nameservers, domain) of the VPN provider is outdated. This happens when
> same VPN is re-connected after transport service has been changed.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 27 Sep 2018 08:51:49 +0200
From: Daniel Wagner <w...@monom.org>
To: Jussi Laakkonen <jussi.laakko...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH] vpn: Add remove function callback to VPN driver
Message-ID: <db1365da-fee9-53aa-767a-385429d2c...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jussi,
On 09/25/2018 03:54 PM, Jussi Laakkonen wrote:
> This commit adds remove function callback to the VPN driver structure.
> The prototype is int (remove*) (struct vpn_provider *provider) and is to
> be registered within the VPN plugin.
>
> This function is called from vpn/plugins/vpn.c when removing a provider
> after it has been stopped. It is meant for VPNs that need to cleanup
> some VPN specific content when removed or to notify other services after
> removal.
Patch applied. I fixed up the small white space glitch.
Applying: vpn: Add remove function callback to VPN driver
.git/rebase-apply/patch:44: trailing whitespace.
warning: 1 line adds whitespace errors.
Anyway, thanks a lot for your work!
Daniel
------------------------------
Message: 5
Date: Thu, 27 Sep 2018 08:54:16 +0200
From: Daniel Wagner <w...@monom.org>
To: Slava Monich <slava.mon...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH] vpn: Fix memory leak
Message-ID: <ba9769e5-3e0f-bd41-fa58-18f35e471...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Slava,
On 09/18/2018 02:44 PM, Slava Monich wrote:
> ==8003== 14 bytes in 1 blocks are definitely lost in loss record 844 of 3,229
> ==8003== at 0x483F3EC: malloc (vg_replace_malloc.c)
> ==8003== by 0x4CD30DF: g_malloc (gmem.c)
> ==8003== by 0x4CEA185: g_strdup (gstrfuncs.c)
> ==8003== by 0x4CEB78B: g_strdupv (gstrfuncs.c)
> ==8003== by 0x4949B: resolv_result (vpn.c)
> ==8003== by 0x2ACC3: sort_and_return_results (gresolv.c)
> ==8003== by 0x2B667: parse_response (gresolv.c)
> ==8003== by 0x2B773: received_udp_data (gresolv.c)
> ==8003== by 0x4CCE06F: g_main_dispatch (gmain.c)
> ==8003== by 0x4CCE06F: g_main_context_dispatch (gmain.c)
> ==8003== by 0x4CCE58F: g_main_loop_run (gmain.c)
> ==8003== by 0x5430B: main (main.c)
Patch applied.
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 27 Sep 2018 09:55:57 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
To: Daniel Wagner <w...@monom.org>, connman@lists.01.org
Subject: Re: [PATCH] vpn: Add remove function callback to VPN driver
Message-ID: <6bcca261-59f2-d715-1b3f-1e3d4779d...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 9/27/18 9:51 AM, Daniel Wagner wrote:
> Hi Jussi,
>
> On 09/25/2018 03:54 PM, Jussi Laakkonen wrote:
>> This commit adds remove function callback to the VPN driver structure.
>> The prototype is int (remove*) (struct vpn_provider *provider) and is to
>> be registered within the VPN plugin.
>>
>> This function is called from vpn/plugins/vpn.c when removing a provider
>> after it has been stopped. It is meant for VPNs that need to cleanup
>> some VPN specific content when removed or to notify other services after
>> removal.
>
> Patch applied. I fixed up the small white space glitch.
>
> Applying: vpn: Add remove function callback to VPN driver
> .git/rebase-apply/patch:44: trailing whitespace.
>
> warning: 1 line adds whitespace errors.
>
> Anyway, thanks a lot for your work!
> Daniel
Thanks,
Sorry, I must have missed that warning. I'll pay more attention to these
patch files next time.
- Jussi
------------------------------
Message: 7
Date: Thu, 27 Sep 2018 08:58:37 +0200
From: Daniel Wagner <w...@monom.org>
To: Slava Monich <slava.mon...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH 0/4] VPN tweaks
Message-ID: <9c886e0b-16da-9072-2a4c-4d998addd...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Slava,
On 09/19/2018 12:03 AM, Slava Monich wrote:
> These are basically follow-ups to the recent VPN auto-disconnect
> changes, on top of the memory leak fix that was sent separately.
All patches applied.
Thanks,
Daniel
------------------------------
Message: 8
Date: Thu, 27 Sep 2018 08:59:33 +0200
From: Daniel Wagner <w...@monom.org>
To: Jussi Laakkonen <jussi.laakko...@jolla.com>, connman@lists.01.org
Subject: Re: [PATCH] vpn: Add remove function callback to VPN driver
Message-ID: <32f731e3-b4a5-cc32-6813-b60df09bd...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
> Sorry, I must have missed that warning. I'll pay more attention to these
> patch files next time.
No worries. This was easy to fix :)
------------------------------
Message: 9
Date: Thu, 27 Sep 2018 17:54:56 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
To: connman@lists.01.org
Subject: [PATCH] vpn: Save provider configuration when properties are
changed
Message-ID: <20180927145456.17973-1-jussi.laakko...@jolla.com>
This commit adds saving of provider configuration when a property
is added, changed or cleared via net.connman.vpn D-Bus interface
net.connman.vpn.Connection using SetProperty or ClearProperty
methods.
---
vpn/vpn-provider.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index dd54ac08..adc41754 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -91,6 +91,7 @@ struct vpn_provider {
static void append_properties(DBusMessageIter *iter,
struct vpn_provider *provider);
+static int vpn_provider_save(struct vpn_provider *provider);
static void free_route(gpointer data)
{
@@ -456,6 +457,8 @@ static DBusMessage *set_property(DBusConnection *conn,
DBusMessage *msg,
vpn_provider_set_string(provider, name, str);
}
+ vpn_provider_save(provider);
+
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
@@ -484,6 +487,8 @@ static DBusMessage *clear_property(DBusConnection *conn,
DBusMessage *msg,
return __connman_error_invalid_property(msg);
}
+ vpn_provider_save(provider);
+
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
--
2.11.0
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 35, Issue 12
***************************************
