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: [PATCH v2 1/5] session: add parameter Service into
createsession call of ConnMan session API (Daniel Wagner)
2. Re: [PATCH v2 2/5] session: Callback hook for policy plugins
to update session state (Daniel Wagner)
3. Re: [PATCH v2 3/5] service: Query function to retrieve
service handle (Daniel Wagner)
4. Re: [PATCH v2 4/5] session: Callback hook for policy plugin
to return service of session (Daniel Wagner)
5. Re: [PATCH v2 5/5] session: Interface to query session->mark
value (Daniel Wagner)
6. Re: Ralink Wifi initialization (Daniel Wagner)
7. Re: Best Practices to reestablish DHCP Ethernet (Daniel Wagner)
8. RE: Best Practices to reestablish DHCP Ethernet (Bill)
9. [PATCH] device: Empty networks table before freeing device
ident (Slava Monich)
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 May 2017 22:18:36 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Cc: Bjoern Thorwirth <[email protected]>,
[email protected]
Subject: Re: [PATCH v2 1/5] session: add parameter Service into
createsession call of ConnMan session API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
Sorry for the long delay. The days don't enough hours. Anyway, this
version looks really good. Some minor stuff.
On 04/25/2017 11:44 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> It is extension to the session API interface. It enables a service
> differentiation
> for processes run by the same user. It allows ConnMan to differentiate
> between bearer
> usage permissions and the respective priorities based on the requested
> service type.
>
> Usually calling process that implements the session API is identified by the
> user ID
> as it is runs. All processes of the same user share the same list of allowed
> bearers,
> and the same priority for choosing between available bearers is applied.
>
> With the proposed changes, extension allows processes to select a service
> context
> for which the routing decision is made.
'With the proposed changes' sounds a bit strange. Just say 'This
extensions or so.
> diff --git a/src/session.c b/src/session.c
> index 1f80b14..b77d9dc 100644
> --- a/src/session.c
> +++ b/src/session.c
> @@ -549,6 +549,7 @@ struct creation_data {
> GSList *allowed_bearers;
> char *allowed_interface;
> bool source_ip_rule;
> + char *service;
> };
>
> static void cleanup_creation_data(struct creation_data *creation_data)
> @@ -558,6 +559,8 @@ static void cleanup_creation_data(struct creation_data
> *creation_data)
>
> if (creation_data->pending)
> dbus_message_unref(creation_data->pending);
> + if (creation_data->service)
> + g_free(creation_data->service);
>
> g_slist_free(creation_data->allowed_bearers);
> g_free(creation_data->allowed_interface);
> @@ -1475,6 +1478,9 @@ int __connman_session_create(DBusMessage *msg)
>
> connman_session_parse_connection_type(val);
>
> user_connection_type = true;
> + } else if (g_str_equal(key, "Service")) {
> + dbus_message_iter_get_basic(&value, &val);
> + creation_data->service = g_strdup(val);
> } else if (g_str_equal(key, "AllowedInterface")) {
> dbus_message_iter_get_basic(&value, &val);
> creation_data->allowed_interface =
> g_strdup(val);
You need also to add the corresponding snippet to append_notify().
Furthermore, please update the documentation.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 3 May 2017 22:21:39 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], Bjoern Thorwirth
<[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH v2 2/5] session: Callback hook for policy plugins
to update session state
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bjoern,
On 04/25/2017 11:45 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> Called when state of session changes.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 3 May 2017 22:25:07 +0200
From: Daniel Wagner <[email protected]>
To: Bjoern Thorwirth <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2 3/5] service: Query function to retrieve
service handle
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bjoern,
On 04/25/2017 11:45 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> Query function to retrieve service handle for service identifier string
Patch applied after tweaking the commit message a bit.
Thanks,
Daniel
------------------------------
Message: 4
Date: Wed, 3 May 2017 22:41:04 +0200
From: Daniel Wagner <[email protected]>
To: Bjoern Thorwirth <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2 4/5] session: Callback hook for policy plugin
to return service of session
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bjoern,
On 04/25/2017 11:45 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> Returns the allowed service for a session based on a provided list of
> available services.
Patch applied after fixing a couple of white space damages.
Thanks,
Daniel
------------------------------
Message: 5
Date: Wed, 3 May 2017 22:44:06 +0200
From: Daniel Wagner <[email protected]>
To: Bjoern Thorwirth <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2 5/5] session: Interface to query session->mark
value
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bjoern,
On 04/25/2017 11:45 AM, [email protected] wrote:
> From: Bjoern Thorwirth <[email protected]>
>
> Will return the session mark
> (without needing to expose the complete struct connman_session)
Patch applied after removing the empty line add.
Thanks,
Daniel
------------------------------
Message: 6
Date: Wed, 3 May 2017 22:50:27 +0200
From: Daniel Wagner <[email protected]>
To: Steven Osborn <[email protected]>
Cc: [email protected]
Subject: Re: Ralink Wifi initialization
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Steven,
On 05/02/2017 06:40 PM, Steven Osborn wrote:
> We're using a Ralink wifi adapter ( Ralink Technology, Corp. RT5370
> Wireless Adapter ) on a custom board with a AM3358 chip (Basically a
> glorified beaglebone).
>
> For some reason when the board boots it quite often the wifi ends up
> in a bad state and won't connect. Running `connmanctl disable wifi`
> followed by `connmanctl enable wifi` will fix it, but not simply
> running enable without first running disable.
>
> Any ideas why this might be happening? Any feedback / solutions is
> greatly appreciated.
Sounds really like a driver problem. The simplest idea obviously is to
let ConnMan print the debug outputs via '-d'. With this we can at least
see what ConnMan thinks is happening. Next step is looking what
wpa_supplicant is doing by enabling the debug output.
And if you a brave you could also give iwd a try and see if that one is
getting the wifi working :)
Thanks,
Daniel
------------------------------
Message: 7
Date: Wed, 3 May 2017 22:59:27 +0200
From: Daniel Wagner <[email protected]>
To: Bill <[email protected]>
Cc: [email protected]
Subject: Re: Best Practices to reestablish DHCP Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Bill,
On 04/27/2017 01:20 AM, Bill wrote:
> I have a number of Debian Jessie Beaglebones running DHCP using Connman
> 1.33 in the field at various customer sites with multiple Network
> providers and routers. All work well except two which seem to lose
> ethernet IP?s at random intervals but always come back after a physical
> box reboot.
All the beaglebones are exactly the same? Are all of them working in the
same network, attached to the same switch?
> What is the appropriate action to take in code when connectivity is lost
> for say 5 mins due to an unknown problem:
>
> Service connman restart ?
Well in theory ConnMan should handles this correctly. But as quick
workaround having a watchdog restarting ConnMan sounds like a good idea.
> Something else?
Obvoulsy, it would be good to figure out what causes this problem and
try to fix that in ConnMan :)
> Do I need to renew dhclient or is it not used by Connman?
ConnMan has an internal DHCP client. If you run dhclient concurrent to
ConnMan you will get two IP address assigned to the same interface.
> Further, would you expect Connman to ALWAYS just work & pull a non 169
> IP after recovery from a router outage because it keeps trying to get
> a real address ? suggesting something more serious has happened that
> may require me to reboot my HW?
If DHCP doesn't work, ConnMan falls back to link local addresses. But it
will keep trying DHCP (using a simple backoff algorithm). Can you check
if ConnMan sees the LOWER_UP on the interface?
> I realize that the best approach is to solve the problem but with no
> control over the customer?s equipment I want to have a reasonable ?get
> me back? system.
For the time being until we find the real source of the problem the
watchdog could mitigate the issue.
Thanks,
Daniel
------------------------------
Message: 8
Date: Wed, 3 May 2017 18:08:31 -0400
From: "Bill" <[email protected]>
To: "'Daniel Wagner'" <[email protected]>
Cc: <[email protected]>
Subject: RE: Best Practices to reestablish DHCP Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel,
That's for the info.
The Beaglebones are a mix of Blacks and Greens but all have the same image.
The Internet equipment is different at almost every site with a mix of 4
providers.
I have 12 sites working flawlessly and two that seem to quit in the middle
of the night 3-4 times per week. Because this happens primarily at night I
suspect forced IP changes ( lease revocation) by the provider.
It sounds like Connman should 'just work' and request a real IP after the
edge router gets back online even if it was down for a while.
I have hooked up a Connman Restart every 5 mins of no connectivity and this
did work last night (2am) at one of the 'bad' sites.
Next step for me is to write some Python to interrogate, log and report ETH0
ip and state during the outages.
Once I have some data I will post it so you can take a look.
Thanks
Bill
-----Original Message-----
From: Daniel Wagner [mailto:[email protected]]
Sent: Wednesday, May 3, 2017 4:59 PM
To: Bill <[email protected]>
Cc: [email protected]
Subject: Re: Best Practices to reestablish DHCP Ethernet
Hi Bill,
On 04/27/2017 01:20 AM, Bill wrote:
> I have a number of Debian Jessie Beaglebones running DHCP using
> Connman
> 1.33 in the field at various customer sites with multiple Network
> providers and routers. All work well except two which seem to lose
> ethernet IP's at random intervals but always come back after a
> physical box reboot.
All the beaglebones are exactly the same? Are all of them working in the
same network, attached to the same switch?
> What is the appropriate action to take in code when connectivity is
> lost for say 5 mins due to an unknown problem:
>
> Service connman restart ?
Well in theory ConnMan should handles this correctly. But as quick
workaround having a watchdog restarting ConnMan sounds like a good idea.
> Something else?
Obvoulsy, it would be good to figure out what causes this problem and try to
fix that in ConnMan :)
> Do I need to renew dhclient or is it not used by Connman?
ConnMan has an internal DHCP client. If you run dhclient concurrent to
ConnMan you will get two IP address assigned to the same interface.
> Further, would you expect Connman to ALWAYS just work & pull a non
> 169 IP after recovery from a router outage because it keeps trying
> to get a real address - suggesting something more serious has
> happened that may require me to reboot my HW?
If DHCP doesn't work, ConnMan falls back to link local addresses. But it
will keep trying DHCP (using a simple backoff algorithm). Can you check if
ConnMan sees the LOWER_UP on the interface?
> I realize that the best approach is to solve the problem but with no
> control over the customer's equipment I want to have a reasonable 'get
> me back' system.
For the time being until we find the real source of the problem the watchdog
could mitigate the issue.
Thanks,
Daniel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------
Message: 9
Date: Thu, 4 May 2017 17:40:04 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: [PATCH] device: Empty networks table before freeing device
ident
Message-ID: <[email protected]>
Networks still need it when they are being deallocated:
#0 connman_device_get_ident (src/device.c)
#1 __connman_network_get_ident (src/network.c)
#2 connman_service_lookup_from_network (src/service.c)
#3 __connman_service_remove_from_network (src/service.c)
#4 network_remove (src/network.c)
#5 __connman_network_set_device (src/network.c)
#6 free_network (src/device.c)
#7 g_hash_table_remove_all_nodes (ghash.c)
#9 g_hash_table_remove_all (ghash.c)
#10 g_hash_table_destroy (ghash.c)
#11 device_destruct (src/device.c)
which results in use after free.
---
src/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/device.c b/src/device.c
index 2e1a3cd..4711290 100644
--- a/src/device.c
+++ b/src/device.c
@@ -384,6 +384,9 @@ static void device_destruct(struct connman_device *device)
clear_pending_trigger(device);
+ g_hash_table_destroy(device->networks);
+ device->networks = NULL;
+
g_free(device->ident);
g_free(device->node);
g_free(device->name);
@@ -393,9 +396,6 @@ static void device_destruct(struct connman_device *device)
g_free(device->last_network);
- g_hash_table_destroy(device->networks);
- device->networks = NULL;
-
g_free(device);
}
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 19, Issue 2
**************************************
