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: Bluetooth services does not appear (Ferry Toth)
2. [PATCH] timeserver: Filter out non working IP addresses
(Daniel Wagner)
3. Re: Bluetooth services does not appear (Daniel Wagner)
4. Re: [PATCH 1/2] service: track g_timeout for wispr try
(Daniel Wagner)
5. Re: [PATCH 2/2] service: retry online check permanently until
success (Daniel Wagner)
6. Re: disconnect_code == 1 from wpa_s results in wrong state in
wifi tech (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 10 Mar 2019 14:02:48 +0100
From: Ferry Toth <[email protected]>
To: Daniel Wagner <[email protected]>, David Lechner
<[email protected]>, Andy Shevchenko <[email protected]>
Cc: [email protected]
Subject: Re: Bluetooth services does not appear
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Op 14-02-19 om 23:01 schreef Ferry Toth:
>
> Op 14-02-19 om 20:51 schreef Daniel Wagner:
>> On Tue, Jan 29, 2019 at 09:49:13PM -0600, David Lechner wrote:
>>> On 1/29/19 2:22 PM, Ferry Toth wrote:
>>>> Op 09-01-19 om 16:51 schreef Daniel Wagner:
>>>>>> root@edison:~# connmanctl
>>>>>> connmanctl> services
>>>>>> *AR Wired??????????????? ethernet_00800f951d4d_cable
>>>>>> ????? Ferry Toth (Galaxy Note3) bluetooth_43341B001FAC_C462EA01AF74
>>>>>> connmanctl> connect bluetooth_43341B001FAC_C462EA01AF74
>>>>>> Error /net/connman/service/bluetooth_43341B001FAC_C462EA01AF74:
>>>>>> Input/output error
>>>>>>
>>>>>> Seems like 1 more thing is missing.
>>>>> Something interesting in the logs?
>>>> I posted debug logs. Did you have a look?
>>> I had a look, but I didn't see anything helpful. Sorry.
>> Me neither.
>>
>>> Maybe there is something in the BlueZ/bluetoothd logs?
>>>
>>> Maybe you are missing a kernel option that needs to be
>>> enabled for ConnMan or BlueZ?
> I have read the parts relating to the kernel config. I think I have
> everything. But then again, it's not working.
>> Hmm, good idea. If it would be oFono my tip would CONFIG_TUN. Almost :(
> Could d-bus be blocking something? This my bluetooth.conf:
>
> <!-- This configuration file specifies the required security policies
> ???? for Bluetooth core daemon to work. -->
>
> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus
> Configuration 1.0//EN"
> "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
> <busconfig>
>
> ? <!-- ../system.conf have denied everything, so we just punch some
> holes -->
>
> ? <policy user="root">
> ??? <allow own="org.bluez"/>
> ??? <allow send_destination="org.bluez"/>
> ??? <allow send_interface="org.bluez.Agent1"/>
> ??? <allow send_interface="org.bluez.MediaEndpoint1"/>
> ??? <allow send_interface="org.bluez.MediaPlayer1"/>
> ??? <allow send_interface="org.bluez.Profile1"/>
> ??? <allow send_interface="org.bluez.GattCharacteristic1"/>
> ??? <allow send_interface="org.bluez.GattDescriptor1"/>
> ??? <allow send_interface="org.bluez.LEAdvertisement1"/>
> ??? <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
> ??? <allow send_interface="org.freedesktop.DBus.Properties"/>
> ? </policy>
>
> ? <policy at_console="true">
> ??? <allow send_destination="org.bluez"/>
> ? </policy>
>
> ? <!-- allow users of lp group (printing subsystem) to
> ?????? communicate with bluetoothd -->
> ? <policy group="lp">
> ??? <allow send_destination="org.bluez"/>
> ? </policy>
>
> ? <policy context="default">
> ??? <deny send_destination="org.bluez"/>
> ? </policy>
>
> </busconfig>
Solved this, thanks Andy Shevchenko.
It appears on Edison (and some other BT devices too), bd_addr is not
stored in OTP. For instance on Edison it is stored in a partition on the
eMMC (/factory). The bcm driver (BCM43341B0) bases the default bd_addr
on the chip (43:34:1B:00:1F:AC), which is fine for most BT services, but
apparently not for pan/nap. It seems like the bnep device is created and
then immediately removed again. The only thing missing is error handling
of this case.
Using the bdaddr tool to set the address makes connman connect to
bluetooth service without problems.
>> Thanks,
>> Daniel
------------------------------
Message: 2
Date: Sun, 10 Mar 2019 18:27:00 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] timeserver: Filter out non working IP addresses
Message-ID: <[email protected]>
The DHCP server or the user might specify an IP address which can't be
reached via the current interface configuration. For example the
timeserver is only reachable via IPv6 but the interface is running in
IPv4 only mode.
We need to make sure we operate on IP addresses which can be in theory
work (filter in __connman_timeserver_sync()). The user is also able to
provide timeserver as hostname, therefore we are filtering in
resolv_result() as well.
As side effect, we start to carefully check if a lookup is already
running, because __connman_timeserver_sync() could be called several
times for one service. For example once from the service state
machine (indicate state) and once from the DHCP code path.
This was reported by the libreelec community:
connmand[421]: Time request for server 2001:3a0:0:2006::87:123 failed
(101/Network is unreachable)
connmand[421]: Time request for server 2a02:2a50:6::123 failed (101/Network is
unreachable)
connmand[421]: Time request for server 2406:2000:e4:a1f::1000 failed
(101/Network is unreachable)
---
Hi,
I tested this lightly and it seems to fix the above problem.
@chewitt: I'd like to hear if this resolve the reported problem :)
Thanks,
Daniel
src/timeserver.c | 77 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 69 insertions(+), 8 deletions(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index 657b782985f4..ebf991bbf8b7 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -34,6 +34,7 @@
#define TS_RECHECK_INTERVAL 7200
+static struct connman_service *ts_service;
static GSList *timeservers_list = NULL;
static GSList *ts_list = NULL;
static char *ts_current = NULL;
@@ -94,29 +95,60 @@ static char **load_timeservers(void)
return servers;
}
+static bool is_timerserver_reachable(struct connman_service *service,
+ const char *host)
+{
+ bool connected;
+ int family;
+
+ family = connman_inet_check_ipaddress(host);
+ connected = __connman_service_is_connected_state(service,
+ CONNMAN_IPCONFIG_TYPE_IPV4);
+ if (family == AF_INET && connected)
+ return true;
+
+ connected = __connman_service_is_connected_state(service,
+ CONNMAN_IPCONFIG_TYPE_IPV6);
+ if (family == AF_INET6 && connected)
+ return true;
+
+ return false;
+}
+
static void resolv_result(GResolvResultStatus status, char **results,
gpointer user_data)
{
+ char *timeserver;
int i;
DBG("status %d", status);
if (status == G_RESOLV_RESULT_STATUS_SUCCESS) {
if (results) {
+ timeserver = NULL;
for (i = 0; results[i]; i++) {
DBG("result[%d]: %s", i, results[i]);
- if (i == 0)
+
+ if (!is_timerserver_reachable(ts_service,
+ results[i]))
continue;
+ if (!timeserver) {
+ timeserver = results[i];
+ continue;
+ }
+
ts_list = __connman_timeserver_add_list(
ts_list, results[i]);
}
- DBG("Using timeserver %s", results[0]);
+ if (timeserver) {
+ DBG("Using timeserver %s", results[0]);
- __connman_ntp_start(results[0], ntp_callback, NULL);
+ __connman_ntp_start(timeserver, ntp_callback,
NULL);
- return;
+ return;
+ }
}
}
@@ -352,6 +384,32 @@ static void ts_recheck_enable(void)
NULL);
}
+static void get_timeserver(struct connman_service *service)
+{
+ GSList *ts, *list;
+ char *timeserver;
+
+ g_slist_free_full(timeservers_list, g_free);
+ timeservers_list = NULL;
+
+ ts = __connman_timeserver_get_all(service);
+ if (!ts)
+ return;
+
+ for (list = ts; list; list = list->next) {
+ timeserver = list->data;
+
+ if (connman_inet_check_ipaddress(timeserver) &&
+ !is_timerserver_reachable(service, timeserver))
+ continue;
+
+ timeservers_list = g_slist_append(timeservers_list,
+ g_strdup(timeserver));
+ }
+
+ g_slist_free_full(ts, g_free);
+}
+
/*
* This function must be called everytime the default service changes, the
* service timeserver(s) or gateway changes or the global timeserver(s)
changes.
@@ -370,6 +428,9 @@ int __connman_timeserver_sync(struct connman_service
*default_service)
if (!service)
return -EINVAL;
+ if (service == ts_service)
+ return -EALREADY;
+
if (!resolv)
return 0;
/*
@@ -395,10 +456,7 @@ int __connman_timeserver_sync(struct connman_service
*default_service)
g_strfreev(nameservers);
- g_slist_free_full(timeservers_list, g_free);
-
- timeservers_list = __connman_timeserver_get_all(service);
-
+ get_timeserver(service);
__connman_service_timeserver_changed(service, timeservers_list);
if (!timeservers_list) {
@@ -408,6 +466,7 @@ int __connman_timeserver_sync(struct connman_service
*default_service)
ts_recheck_enable();
+ ts_service = service;
timeserver_sync_start();
return 0;
@@ -459,6 +518,8 @@ static void timeserver_stop(void)
{
DBG(" ");
+ ts_service = NULL;
+
if (resolv) {
g_resolv_unref(resolv);
resolv = NULL;
--
2.20.1
------------------------------
Message: 3
Date: Sun, 10 Mar 2019 18:32:51 +0100
From: Daniel Wagner <[email protected]>
To: Ferry Toth <[email protected]>, David Lechner
<[email protected]>, Andy Shevchenko <[email protected]>
Cc: [email protected]
Subject: Re: Bluetooth services does not appear
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Ferry,
> Solved this, thanks Andy Shevchenko.
>
> It appears on Edison (and some other BT devices too), bd_addr is not
> stored in OTP. For instance on Edison it is stored in a partition on the
> eMMC (/factory). The bcm driver (BCM43341B0) bases the default bd_addr
> on the chip (43:34:1B:00:1F:AC), which is fine for most BT services, but
> apparently not for pan/nap. It seems like the bnep device is created and
> then immediately removed again. The only thing missing is error handling
> of this case.
>
> Using the bdaddr tool to set the address makes connman connect to
> bluetooth service without problems.
Thanks for the feedback.
If I am not completely mistaken, 43:34:1B:00:1F:AC says it is locally
administered address, so you can't reach any routed network.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sun, 10 Mar 2019 18:58:49 +0100
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/2] service: track g_timeout for wispr try
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julien,
On 3/6/19 4:47 PM, Julien Massot wrote:
> From: Julien Massot <[email protected]>
>
> In case we are disconnecting or removing the device,
> the service will keep a ref until the timeout is reached.
>
> Better to cancel the timeout, so that we can drop the ref,
> and remove the service immediatly.
Good point, this make sense.
> ---
> src/service.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/src/service.c b/src/service.c
> index 43233671..6044c601 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -127,6 +127,7 @@ struct connman_service {
> char *pac;
> bool wps;
> bool wps_advertizing;
> + guint online_timeout;
> int online_check_count_ipv4;
> int online_check_count_ipv6;
> bool do_split_routing;
> @@ -5998,13 +5999,8 @@ static void service_rp_filter(struct connman_service
> *service,
> static void redo_wispr(struct connman_service *service,
> enum connman_ipconfig_type type)
> {
> - int refcount = service->refcount - 1;
> -
> + service->online_timeout = 0;
> connman_service_unref(service);
> - if (refcount == 0) {
> - DBG("Service %p already removed", service);
> - return;
> - }
I like :)
>
> DBG("Retrying %s WISPr for %p %s",
> __connman_ipconfig_type2string(type),
> @@ -6062,7 +6058,8 @@ int __connman_service_online_check_failed(struct
> connman_service *service,
> * necessary IPv6 router advertisement messages that might have
> * DNS data etc.
> */
> - g_timeout_add_seconds(1, redo_func, connman_service_ref(service));
> + service->online_timeout = g_timeout_add_seconds(1, redo_func,
> + connman_service_ref(service));
>
> return EAGAIN;
> }
> @@ -6481,6 +6478,15 @@ int __connman_service_connect(struct connman_service
> *service,
> return err;
> }
>
> +static void cancel_online_check(struct connman_service *service)
> +{
> + if (service->online_timeout > 0) {
> + connman_service_unref(service);
> + g_source_remove(service->online_timeout);
> + service->online_timeout = 0;
> + }
> +}
Do an early return:
if (service->online_timeout == 0)
return;
....
> +
> int __connman_service_disconnect(struct connman_service *service)
> {
> int err;
> @@ -6494,6 +6500,8 @@ int __connman_service_disconnect(struct connman_service
> *service)
>
> __connman_stats_service_unregister(service);
>
> + cancel_online_check(service);
Hmm, not sure if this the right place to cancel. Especially when you
need to add the following cancel.
> +
> if (service->network) {
> err = __connman_network_disconnect(service->network);
> } else if (service->type == CONNMAN_SERVICE_TYPE_VPN &&
> @@ -7280,6 +7288,7 @@ void __connman_service_remove_from_network(struct
> connman_network *network)
> __connman_connection_gateway_remove(service,
> CONNMAN_IPCONFIG_TYPE_ALL);
>
> + cancel_online_check(service);
> connman_service_unref(service);
> }
The state machine changes happen in
__connman_service_ipconfig_indicate_state(). I think this call should be
placed there once.
Thanks,
Daniel
------------------------------
Message: 5
Date: Sun, 10 Mar 2019 19:05:20 +0100
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 2/2] service: retry online check permanently until
success
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julien,
On 3/6/19 4:47 PM, Julien Massot wrote:
> From: Julien Massot <[email protected]>
>
> This make online check happen right after ready state, and
> then after ONLINE_CHECK_INITIAL_INTERVAL (1 second) like before,
> and then happen after + ONLINE_CHECK_INCREMENT_INTERVAL until
> reaching the maximum interval ONLINE_CHECK_MAX_INTERVAL.
>
> Once we reached the ready state we stop online check.
Well, having some sort of backoff algorithm make sense to me. One thing
I am wondering if the linear backoff is the right thing to do. Maybe we
could do a short poll interval and then increase the poll interval. Just
like we have now for timeservers as well, which seems to make a lot of
RaspberryPi users happy :)
I don't have a lot of experience here. So if you say this the right
thing to do, that's fine with me.
Thanks,
Daniel
------------------------------
Message: 6
Date: Sun, 10 Mar 2019 19:39:13 +0100
From: Daniel Wagner <[email protected]>
To: Henrik Persson <[email protected]>
Cc: connman <[email protected]>, Olof Winge
<[email protected]>
Subject: Re: disconnect_code == 1 from wpa_s results in wrong state in
wifi tech
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Henrik,
Thanks for your report.
On Thu, Mar 07, 2019 at 11:44:17AM +0000, Henrik Persson wrote:
> In wifi.c:interface_state() line 2546 or so it says that we assume
> that reason 1 is because we are blocked. We also seem to assume that
> this is thrown when we are connecting, so we call
> connman_network_set_error(network,
> CONNMAN_NETWORK_ERROR_BLOCKED). This trickles down into
> service.c:service_indicate_state() line 5795 or so where
> connman_agent_report_error() is called. In my case I do have an
> agent registered, so that call will return -EINPROGRESS which will
> make service_indicate_state() to return then and there, calling SOME
> of the functions below on completion, but not
> __connman_notifier_disconnect(), which would ultimately have
> triggered the technology change to connected=false.
Okay, so we leave service_indicate_state() to early and get the state
machine into inconsistent state. I digged a bit through the history
and I didn't find any good explanation why we return early.
I suppose we should do something like (completly untested):
diff --git a/src/service.c b/src/service.c
index f6fe81bf7c95..f301ab050588 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5793,16 +5793,14 @@ static int service_indicate_state(struct
connman_service *service)
break;
case CONNMAN_SERVICE_STATE_FAILURE:
-
- if (service->connect_reason ==
CONNMAN_SERVICE_CONNECT_REASON_USER &&
+ if (service->connect_reason ==
CONNMAN_SERVICE_CONNECT_REASON_USER) {
connman_agent_report_error(service, service->path,
- error2string(service->error),
- report_error_cb,
- get_dbus_sender(service),
- NULL) == -EINPROGRESS)
- return 0;
+ error2string(service->error),
+ report_error_cb,
+ get_dbus_sender(service),
+ NULL);
+ }
service_complete(service);
-
break;
}
connman_agent_report_error() will do a log entry if something goes
wrong. So we don't have to log it here. So could silenty go ahead and
update the state machine.
> I don't know if this should be fixed in service_indicate_state() so
> that we would make sure that __connman_notifier_disconnect() is
> called, or in wifi.c to add something like this:
>
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index f8c22be3..27dfb07c 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -2546,8 +2546,9 @@ static void interface_state(GSupplicantInterface
> *interface)
> /* Let's assume it's because we got blocked */
>
> case 6: /* Class 2 frame received from nonauthenticated STA */
> - connman_network_set_error(network,
> - CONNMAN_NETWORK_ERROR_BLOCKED);
> + if (!wifi->connected)
> + connman_network_set_error(network,
> +
> CONNMAN_NETWORK_ERROR_BLOCKED);
> break;
>
> default:
The blocked error code should always be propagated. E.g. the admin
decides to kick from the network, so that means we have been online
and we should propage that to the user.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 41, Issue 10
***************************************
