Send connman mailing list submissions to
[email protected]
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
[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: [RFC v0 08/10] iwd: Add/remove ConnMan devices (Denis Kenzior)
2. Re: [RFC v0 05/10] iwd: Track D-Bus API (Daniel Wagner)
3. Re: [RFC v0 08/10] iwd: Add/remove ConnMan devices (Daniel Wagner)
4. Re: Support fro strongswan in Connman (Daniel Wagner)
5. Re: [PATCH v2] service: Update nameservers automatically
(Feng Wang)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Nov 2016 11:11:07 -0600
From: Denis Kenzior <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [RFC v0 08/10] iwd: Add/remove ConnMan devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Daniel,
> @@ -170,6 +185,18 @@ static struct connman_network_driver
network_driver = {
>
> static int cm_device_probe(struct connman_device *device)
> {
> + GHashTableIter iter;
> + gpointer key, value;
> +
> + g_hash_table_iter_init(&iter, devices);
> +
> + while (g_hash_table_iter_next(&iter, &key, &value)) {
> + struct iwd_device *iwdd = value;
> +
> + if (device == iwdd->device)
> + return 0;
> + }
> +
Not an expert on connman design, but this seems like a really expensive
no-op. Out of curiosity, why is this necessary?
> return -EOPNOTSUPP;
> }
>
Regards,
-Denis
------------------------------
Message: 2
Date: Thu, 10 Nov 2016 18:20:32 +0100
From: Daniel Wagner <[email protected]>
To: Denis Kenzior <[email protected]>, [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [RFC v0 05/10] iwd: Track D-Bus API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Denis,
On 11/10/2016 05:46 PM, Denis Kenzior wrote:
>> + } else if (!strcmp(name, "Address")) {
>> + const char *address;
>> +
>> + dbus_message_iter_get_basic(iter, &address);
>> + g_free(iwdd->address);
>> + iwdd->address = g_strdup(address);
>> +
>> + DBG("%p address %s", path, iwdd->address);
>
> I don't imagine we will ever notify PropertyChanged for Address or Name.
> Though I suppose it doesn't hurt to have it here
I was not sure if this is needed. Hmm, I guess it would also need some
more thinking how to handle it. We derive a 'unique' id from the
address. Hmm, maybe we just should remove the whole network and create
it new if that ever changes.
>
>> + } else if (!strcmp(name, "State")) {
>> + const char *state;
>> +
>> + dbus_message_iter_get_basic(iter, &state);
>> + iwdd->state = string2state(state);
>> +
>> + DBG("%s state %s", path, state2string(iwdd->state));
>> + } else if (!strcmp(name, "Powered")) {
>> + dbus_bool_t powered;
>> +
>> + dbus_message_iter_get_basic(iter, &powered);
>> + iwdd->powered = powered;
>> +
>> + DBG("%s powered %d", path, iwdd->powered);
>> +
>
> extraneous line?
Yep.
>> + } else if (!strcmp(name, "Scanning")) {
>> + dbus_bool_t scanning;
>> +
>> + dbus_message_iter_get_basic(iter, &scanning);
>> + iwdd->scanning = scanning;
>> +
>> + DBG("%s scanning %d", path, iwdd->scanning);
>> + }
>> +}
>> +
>> +static void network_property_change(GDBusProxy *proxy, const char *name,
>> + DBusMessageIter *iter, void *user_data)
>> +{
>> + struct iwd_network *iwdn;
>> + const char *path;
>> +
>> + path = g_dbus_proxy_get_path(proxy);
>> + iwdn = g_hash_table_lookup(networks, path);
>> + if (!iwdn)
>> + return;
>> +
>> + if (!strcmp(name, "Name")) {
>> + const char *name;
>> +
>> + dbus_message_iter_get_basic(iter, &name);
>> + g_free(iwdn->name);
>> + iwdn->name = g_strdup(name);
>> +
>> + DBG("%p name %s", path, iwdn->name);
>
> Same here, the Name == SSID, so I don't think it would ever change. We'd
> create a brand new Network object in this case.
Okay, I'll drop it then here.
>> + } else if (!strcmp(name, "Connected")) {
>> + dbus_bool_t connected;
>> +
>> + dbus_message_iter_get_basic(iter, &connected);
>> + iwdn->connected = connected;
>> +
>> + DBG("%s connected %d", path, iwdn->connected);
>> + } else if (!strcmp(name, "Type")) {
>> + const char *type;
>> +
>> + dbus_message_iter_get_basic(iter, &type);
>> + g_free(iwdn->type);
>> + iwdn->type = g_strdup(type);
>> +
>> + DBG("%p type %s", path, iwdn->type);
>
> Same comment as above.
Good to know. So whenever address, name or type changes we get a new
object from iwd. That makes sense. I'll remove those bits here.
cheers,
daniel
------------------------------
Message: 3
Date: Thu, 10 Nov 2016 18:24:55 +0100
From: Daniel Wagner <[email protected]>
To: Denis Kenzior <[email protected]>, [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: Re: [RFC v0 08/10] iwd: Add/remove ConnMan devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Denis,
On 11/10/2016 06:11 PM, Denis Kenzior wrote:
>> @@ -170,6 +185,18 @@ static struct connman_network_driver
> network_driver = {
>>
>> static int cm_device_probe(struct connman_device *device)
>> {
>> + GHashTableIter iter;
>> + gpointer key, value;
>> +
>> + g_hash_table_iter_init(&iter, devices);
>> +
>> + while (g_hash_table_iter_next(&iter, &key, &value)) {
>> + struct iwd_device *iwdd = value;
>> +
>> + if (device == iwdd->device)
>> + return 0;
>> + }
>> +
>
> Not an expert on connman design, but this seems like a really expensive
> no-op. Out of curiosity, why is this necessary?
This one fixes the problem where the core knows about a device but it
hasn't a mapping to the driver yet. Some devices show faster up in RTNL
then the driver handles it. IIRC wpa_s is one of those sources. Can't
remember the details. I agree, it is ugly.
cheers,
daniel
------------------------------
Message: 4
Date: Thu, 10 Nov 2016 19:19:14 +0100
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Support fro strongswan in Connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Florent,
On 11/10/2016 05:16 PM, Florent Le Saout wrote:
> I'm using Strongswan for IPsec and connman as network manager.
>
> It seems that there is no support for strongswan in Connman ?
Yes, it looks like we don't do strongswan yet.
> If so then is there any plan to integrate it at some point, or any work
> on that already ongoing ?
I haven't heard or seen anyone working on such a plugin. Obviously, we
wouldn't mind if someone would build such a plugin :)
cheers,
daniel
------------------------------
Message: 5
Date: Thu, 10 Nov 2016 11:41:56 -0800
From: Feng Wang <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: [PATCH v2] service: Update nameservers automatically
Message-ID:
<CADsK2K9H=chvtdkh6znt6c63uxose02geosghplsq1q9ayh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrik,
I verified the patch and it works.
Thanks,
Feng
On Mon, Nov 7, 2016 at 4:48 AM, Daniel Wagner <[email protected]> wrote:
> Hi Patrik,
>
> On 11/04/2016 10:38 AM, Patrik Flykt wrote:
>
>> Automatically update nameserver information when they are appended
>> or removed to the resolver code so that nameservers for IPv6 can be
>> signalled after IPv4 has moved the service to state 'ready'. Create
>> a zero second timeout so that nameservers can be appended or removed
>> in a loop one by one with only one D-Bus PropertyChanged signal
>> being sent.
>>
>> Verify that the service is either connected or the nameservers have
>> been removed when the service is inactive before sending the
>> PropertyChanged signal.
>> ---
>>
>> v2: Move nameserver announcing to the updating of the resolver. This
>> should take care of adding IPv6 nameservers after the service is
>> in state 'ready'.
>>
>> Please test,
>>
>
> In my simple setup it works as expected (no IPv6). I suggest you go ahead
> and apply it. If it breaks something we have a good idea what the source is
> :)
>
> cheers,
> daniel
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161110/a89a603f/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 13, Issue 12
***************************************
