Re: Wi-Fi access point use case - tether DNS and IP address
On 09/15/2015 02:37 AM, Patrik Flykt wrote: 3) How can notifications of tether interface's IP address changes be obtained via D-Bus? As tethering is considered to happen automatically without needing any user intervention, there hasn't been any real need to expose tethered IP address information either. Although ConnMan is light-weight, it's still not a generic embedded routing platform. I have a use case for this as well (not trying to make a router, but just displaying the IP address of the tether interface for informational purposes). The work around that I came up with is to use udev to listen to add, change and remove events. The device is always named "tether" so it is easy to match. If the device is added or changed, I look up the address by using getifaddrs and finding it in the list. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Fix bluetooth plugin implemntation of technology_set returns error.
On 01/14/2015 10:55 PM, David Lechner wrote:
The technology_set implementation in the bluetooth plugin returns
-EINPROGRESS which causes problems.
1. When setting the Tethering property via D-Bus, D-Bus returns an error
instead of completing successfuly.
2. When using the PersistentTetheringMode option, bluetooth tethering
is not remembered. This is because /var/lib/connman/settings is not
updated if technology_set returns an error.
This fixes the issue by returning 0 when bluetooth_tech_set_tethering
completes successfully.
---
plugins/bluetooth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index c6f387e..636c7bf 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -899,7 +899,7 @@ static int bluetooth_tech_set_tethering(struct
connman_technology *technology,
if (i == 0)
return -ENODEV;
- return -EINPROGRESS;
+ return 0;
}
static struct connman_technology_driver tech_driver = {
Just want to make sure this patch did not get overlooked.
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] Fix bluetooth plugin implemntation of technology_set returns error.
The technology_set implementation in the bluetooth plugin returns
-EINPROGRESS which causes problems.
1. When setting the Tethering property via D-Bus, D-Bus returns an error
instead of completing successfuly.
2. When using the PersistentTetheringMode option, bluetooth tethering
is not remembered. This is because /var/lib/connman/settings is not
updated if technology_set returns an error.
This fixes the issue by returning 0 when bluetooth_tech_set_tethering
completes successfully.
---
plugins/bluetooth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index c6f387e..636c7bf 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -899,7 +899,7 @@ static int bluetooth_tech_set_tethering(struct
connman_technology *technology,
if (i == 0)
return -ENODEV;
- return -EINPROGRESS;
+ return 0;
}
static struct connman_technology_driver tech_driver = {
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Tethering on startup?
On 01/13/2015 06:53 PM, Mike Purvis wrote: When I set up connman 1.27 to connect to an AP and then restart my machine, it seems to reconnect okay on startup (most of the time). However, when I set it to create an AP (tether) and restart my machine, it comes up with the wifi idle. Is there a way to have it resume the tethering activity on reboot, or do I need to activate that externally? Obvious choices would be running a connmanctl invocation from rc.local, or running a separate manager process which talks to connmand over dbus and starts it up. Thoughts? Just came across this myself. It is a configurable option in /etc/connman/main.conf. PersistentTetheringMode = true See https://git.kernel.org/cgit/network/connman/connman.git/tree/src/main.conf (at the very end). ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Bluetooth plugin return values.
On 01/13/2015 01:28 AM, Patrik Flykt wrote: On Mon, 2015-01-12 at 17:26 -0600, David Lechner wrote: I noticed that when enabling tethering on bluetooth (using 1.27) that it says Error enabling bluetooth tethering: In progress. Same with disabling: Error disabling bluetooth tethering: In progress. Other technologies (tested wifi and gadget) don't return an error like this. I had a look at plugins/bluetooth.c and quite a few of the functions return -EINPROGRESS upon successful completion. What is the purpose of this? The error is certainly misleading. I'd be glad to write a patch if it is really not necessary. Internally -EINPROGRESS signals that work is taking place to complete whatever the request is. Externally signalling -EINPROGRESS depends a bit on who is doing what. It sounds like this internal usage is leaking externally. With no outstanding requests for a particular task, the initiator of a ConnMan D-Bus method call will have to wait until the task is completed, This does not seem to be happening in the case of enabling/disabling tethering for the bluetooth technology. I am guessing that instead of waiting, the internal -EINPROGRESS is being returned instead. i.e. the D-Bus method call is pending for the initiator. Any subsequent attempt to perform the same task (or another one somehow blocked by the initial task) will receive a -EINPROGRESS or similar pretty much instantly. Right, this is what I would expect, but like I said, this is returning the EINPROGRESS error on the *first* attempt, not on a subsequent attempt. To return to your original question, it actually depends. It may very well be that ConnMan did something internally by itself which the code interpreted as being in progress, it may be there actually was already some other entity doing the same thing or then it's just a plain bug. One should be able to find out whether its a bug or an intended feature by staring at the code. If neither of these applies then a hunt for some other entity doing stuff with ConnMan is started. Usually it should be a well-known issue whether this last scenario is the one happening, but one never knows. I'm not really following you here. I'd say if technology enabling fails regularly from e.g. connmanctl, then it most likely is a bug - patches are welcome :-) The problem is *not* the failure of enabling a technology. It is the return of an error upon success of enabling/disabling tethering on a technology. From your first remarks though, it sounds like a patch is in order so that the -EINPROGRESS does not bubble up from the internal usage all the way to D-Bus when enabling tethering on the first attempt, but rather blocks until the operation is complete. Any attempt to enable tethering again while the first attempt is still blocking would of course return an in progress error via D-Bus. HTH, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Bluetooth plugin return values.
I noticed that when enabling tethering on bluetooth (using 1.27) that it says Error enabling bluetooth tethering: In progress. Same with disabling: Error disabling bluetooth tethering: In progress. Other technologies (tested wifi and gadget) don't return an error like this. I had a look at plugins/bluetooth.c and quite a few of the functions return -EINPROGRESS upon successful completion. What is the purpose of this? The error is certainly misleading. I'd be glad to write a patch if it is really not necessary. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/5] util: Use proper source for random numbers
On 11/17/2014 04:43 AM, Patrik Flykt wrote: Use /dev/urandom as the proper source for random numbers. Verify the existence of /dev/urandom at compile time and program startup. Out of curiosity, why does it matter that we have /dev/urandom at compile time? ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 2/2] Fix crash when role is NULL.
On 11/10/2014 07:30 AM, Patrik Flykt wrote: Applied, thanks! There was a missing semicolon, I fixed that in order to avoid another round-trip to get this working properly. Thanks for cleaning up after me. I thought I had fixed that before I submitted the patch, but I guess not. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] Fix preferred bluetooth role matching.
This fixes an error in the proxy_get_role fuction in commit
6f6927236fc35429eecb1b1459ea5e20ab667db8.
The comment was correct as to what we want to accomplish here, however the
programming logic did not match what the comment says. Now it correctly
returns the most preferred role instead of just the first matching role.
---
plugins/bluetooth.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 924336b..76669c8 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -88,9 +88,10 @@ static bool proxy_get_bool(GDBusProxy *proxy, const char
*property)
return value;
}
-static const char* proxy_get_role(GDBusProxy *proxy)
+static const char *proxy_get_role(GDBusProxy *proxy)
{
-DBusMessageIter iter, value;
+ DBusMessageIter iter, value;
+ const char *pref = NULL;
if (!proxy)
return NULL;
@@ -104,20 +105,20 @@ static const char* proxy_get_role(GDBusProxy *proxy)
dbus_message_iter_get_basic(value, uuid);
/*
-* Order matters here. If a device offers more than one role,
-* we prefer NAP, then GN, then PANU.
+* If a device offers more than one role, we prefer NAP,
+* then GN, then PANU.
*/
if (!strcmp(uuid, BLUETOOTH_PAN_NAP))
return nap;
if (!strcmp(uuid, BLUETOOTH_PAN_GN))
- return gn;
- if (!strcmp(uuid, BLUETOOTH_PAN_PANU))
- return panu;
+ pref = gn;
+ if (!strcmp(uuid, BLUETOOTH_PAN_PANU) !pref)
+ pref = panu;
dbus_message_iter_next(value);
}
- return NULL;
+ return pref;
}
static int bluetooth_pan_probe(struct connman_network *network)
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 2/2] Fix crash when role is NULL.
On 11/03/2014 11:24 PM, David Lechner wrote: This fixes a crash that was introduced in commit 6f6927236fc35429eecb1b1459ea5e20ab667db8. It is possible for the role to be NULL, which caused a crash in strcmp. Just a little more background... I pushed out my Bluetooth GN/PANU patch to a wider audience and immediately found a crash. When pairing a device running connman to Windows 7 using the built-in Microsoft bluetooth stack, it caused connman to crash. It turns out Win7 provides the PANU profile and apparently it connects a little differently than the others. This led to a path where we had NULL as an argument for strcmp which of course caused a SEGV. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] Support connecting to bluetooth GN and PANU roles
Bluetooth PAN specifies three different roles for different types of
network connections, PANU, NAP and GN. ConnMan currently supports NAP
but ignores the other roles. This patch adds support for the GN and
PANU roles so that we can connect to devices that don't offer NAP.
In the case that a device provides more than one role, we prefer NAP
over GN and GN over PANU. ConnMan will only use the most preferred role
and ignore the others so that we don't have duplicate services in
ConnMan.
---
plugins/bluetooth.c | 52 ++--
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 82217d0..924336b 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -36,7 +36,9 @@
#define BLUEZ_SERVICE org.bluez
#define BLUEZ_PATH /org/bluez
+#define BLUETOOTH_PAN_PANU 1115--1000-8000-00805f9b34fb
#define BLUETOOTH_PAN_NAP 1116--1000-8000-00805f9b34fb
+#define BLUETOOTH_PAN_GN1117--1000-8000-00805f9b34fb
#define BLUETOOTH_ADDR_LEN 6
@@ -50,6 +52,7 @@ struct bluetooth_pan {
struct connman_network *network;
GDBusProxy *btdevice_proxy;
GDBusProxy *btnetwork_proxy;
+ const char *pan_role;
};
static void address2ident(const char *address, char *ident)
@@ -85,28 +88,36 @@ static bool proxy_get_bool(GDBusProxy *proxy, const char
*property)
return value;
}
-static bool proxy_get_nap(GDBusProxy *proxy)
+static const char* proxy_get_role(GDBusProxy *proxy)
{
DBusMessageIter iter, value;
if (!proxy)
- return false;
+ return NULL;
if (!g_dbus_proxy_get_property(proxy, UUIDs, iter))
-return false;
+ return NULL;
dbus_message_iter_recurse(iter, value);
while (dbus_message_iter_get_arg_type(value) == DBUS_TYPE_STRING) {
const char *uuid;
-dbus_message_iter_get_basic(value, uuid);
-if (strcmp(uuid, BLUETOOTH_PAN_NAP) == 0)
-return true;
+ dbus_message_iter_get_basic(value, uuid);
+ /*
+* Order matters here. If a device offers more than one role,
+* we prefer NAP, then GN, then PANU.
+*/
+ if (!strcmp(uuid, BLUETOOTH_PAN_NAP))
+ return nap;
+ if (!strcmp(uuid, BLUETOOTH_PAN_GN))
+ return gn;
+ if (!strcmp(uuid, BLUETOOTH_PAN_PANU))
+ return panu;
dbus_message_iter_next(value);
}
-return false;
+ return NULL;
}
static int bluetooth_pan_probe(struct connman_network *network)
@@ -225,9 +236,11 @@ static void pan_connect_cb(DBusMessage *message, void
*user_data)
static void pan_connect_append(DBusMessageIter *iter,
void *user_data)
{
- const char *role = BLUETOOTH_PAN_NAP;
+ const char *path = user_data;
+ struct bluetooth_pan *pan;
- dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, role);
+ pan = g_hash_table_lookup(networks, path);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, pan-pan_role);
}
static int bluetooth_pan_connect(struct connman_network *network)
@@ -322,8 +335,10 @@ static void btnetwork_property_change(GDBusProxy *proxy,
const char *name,
static void pan_create_nap(struct bluetooth_pan *pan)
{
struct connman_device *device;
+ const char* role;
- if (!proxy_get_nap(pan-btdevice_proxy)) {
+ role = proxy_get_role(pan-btdevice_proxy);
+ if (!role) {
pan_remove_nap(pan);
return;
}
@@ -366,6 +381,7 @@ static void pan_create_nap(struct bluetooth_pan *pan)
connman_network_set_group(pan-network, ident);
}
+ pan-pan_role = role;
connman_device_add_network(device, pan-network);
if (pan_connect(pan, NULL))
@@ -376,9 +392,9 @@ static void btdevice_property_change(GDBusProxy *proxy,
const char *name,
DBusMessageIter *iter, void *user_data)
{
struct bluetooth_pan *pan;
- bool pan_nap = false;
+ const char* pan_role = NULL;
- if (strcmp(name, UUIDs) != 0)
+ if (strcmp(name, UUIDs))
return;
pan = g_hash_table_lookup(networks, g_dbus_proxy_get_path(proxy));
@@ -387,12 +403,12 @@ static void btdevice_property_change(GDBusProxy *proxy,
const char *name,
if (pan-network
connman_network_get_device(pan-network))
- pan_nap = true;
+ pan_role = pan-pan_role;
- DBG(network %p network nap %d proxy nap %d, pan-network, pan_nap,
- proxy_get_nap(pan-btdevice_proxy));
+ DBG(network %p network
[PATCH] Support connecting to bluetooth GN and PANU roles
Bluetooth PAN specifies three different roles for different types of
network connections, PANU, NAP and GN. ConnMan currently supports NAP
but ignores the other roles. This patch adds support for the GN and
PANU roles so that we can connect to devices that don't offer NAP.
In the case that a device provides more than one role, we prefer NAP
over GN and GN over PANU. ConnMan will only use the most preferred role
and ignore the others so that we don't have duplicate services in
ConnMan.
---
plugins/bluetooth.c | 50
+-
1 file changed, 33 insertions(+), 17 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 82217d0..6902dd7 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -36,7 +36,9 @@
#define BLUEZ_SERVICE org.bluez
#define BLUEZ_PATH /org/bluez
+#define BLUETOOTH_PAN_PANU
1115--1000-8000-00805f9b34fb
#define BLUETOOTH_PAN_NAP
1116--1000-8000-00805f9b34fb
+#define BLUETOOTH_PAN_GN
1117--1000-8000-00805f9b34fb
#define BLUETOOTH_ADDR_LEN 6
@@ -50,6 +52,7 @@ struct bluetooth_pan {
struct connman_network *network;
GDBusProxy *btdevice_proxy;
GDBusProxy *btnetwork_proxy;
+ const char *pan_role;
};
static void address2ident(const char *address, char *ident)
@@ -85,28 +88,36 @@ static bool proxy_get_bool(GDBusProxy *proxy, const
char *property)
return value;
}
-static bool proxy_get_nap(GDBusProxy *proxy)
+static const char* proxy_get_role(GDBusProxy *proxy)
{
DBusMessageIter iter, value;
if (!proxy)
- return false;
+ return NULL;
if (!g_dbus_proxy_get_property(proxy, UUIDs, iter))
-return false;
+ return NULL;
dbus_message_iter_recurse(iter, value);
while (dbus_message_iter_get_arg_type(value) ==
DBUS_TYPE_STRING) {
const char *uuid;
-dbus_message_iter_get_basic(value, uuid);
-if (strcmp(uuid, BLUETOOTH_PAN_NAP) == 0)
-return true;
+ dbus_message_iter_get_basic(value, uuid);
+ /*
+* Order matters here. If a device offers more than one role,
+* we prefer NAP, then GN, then PANU.
+*/
+ if (strcmp(uuid, BLUETOOTH_PAN_NAP) == 0)
+ return nap;
+ if (strcmp(uuid, BLUETOOTH_PAN_GN) == 0)
+ return gn;
+ if (strcmp(uuid, BLUETOOTH_PAN_PANU) == 0)
+ return panu;
dbus_message_iter_next(value);
}
-return false;
+ return NULL;
}
static int bluetooth_pan_probe(struct connman_network *network)
@@ -225,9 +236,11 @@ static void pan_connect_cb(DBusMessage *message,
void *user_data)
static void pan_connect_append(DBusMessageIter *iter,
void *user_data)
{
- const char *role = BLUETOOTH_PAN_NAP;
+ const char *path = user_data;
+ struct bluetooth_pan *pan;
- dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, role);
+ pan = g_hash_table_lookup(networks, path);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, pan-pan_role);
}
static int bluetooth_pan_connect(struct connman_network *network)
@@ -322,8 +335,10 @@ static void btnetwork_property_change(GDBusProxy
*proxy, const char *name,
static void pan_create_nap(struct bluetooth_pan *pan)
{
struct connman_device *device;
+ const char* role;
- if (!proxy_get_nap(pan-btdevice_proxy)) {
+ role = proxy_get_role(pan-btdevice_proxy);
+ if (!role) {
pan_remove_nap(pan);
return;
}
@@ -366,6 +381,7 @@ static void pan_create_nap(struct bluetooth_pan *pan)
connman_network_set_group(pan-network, ident);
}
+ pan-pan_role = role;
connman_device_add_network(device, pan-network);
if (pan_connect(pan, NULL))
@@ -376,7 +392,7 @@ static void btdevice_property_change(GDBusProxy
*proxy, const char *name,
DBusMessageIter *iter, void *user_data)
{
struct bluetooth_pan *pan;
- bool pan_nap = false;
+ const char* pan_role = NULL;
if (strcmp(name, UUIDs) != 0)
return;
@@ -387,12 +403,12 @@ static void btdevice_property_change(GDBusProxy
*proxy, const char *name,
if (pan-network
connman_network_get_device(pan-network))
- pan_nap = true;
+ pan_role = pan-pan_role;
- DBG(network %p network nap %d proxy nap %d, pan-network, pan_nap,
- proxy_get_nap(pan-btdevice_proxy));
+ DBG(network %p network role %s proxy role %s, pan-network, pan_role,
+ proxy_get_role(pan-btdevice_proxy));
- if (proxy_get_nap(pan-btdevice_proxy) ==
Re: [PATCH] Release references to technologies held by rfkill during cleanup.
On 10/23/2014 08:04 AM, Patrik Flykt wrote: This is caused because there are two plugins for Bluetooth, one for Bluez 4 and the other one for Bluez 5. Both register a connman_technology_driver. So far so good. The problem is caused by technology_get(type) in __connman_technology_add_rfkill(), with more than one technology driver this add function is called multiple times, each time increasing the reference count of the technology by one. It's not that easy to fix, as the technology is created when there is a technology driver present and either an rfkill switch or a connman device is added to the system. While I'm thinking on how to solve this, the UI mopping up after a sudden ConnMan disappearance from D-Bus looks suddenly like a very good and easy solution to the initial problem... I see what you mean. I guess the reason my initial patch seemed like it works is because there was only one extra technology_get called. If there were three Bluetooth drivers, then it would not work. It seems like you might be able to have an rfkill_get and rfkill_put so that the first driver that is registered that calls rfkill_get will call __connman_technology_add_rfkill, but subsequent calls to rfkill_get will just return without calling __connman_technology_add_rfkill. When the last driver is unregistered that calls rfkill_put, then it should in turn call __connman_technology_remove_rfkill. Of course, rfkill_process in src/rfkill.c would have to be modified to work with this as well. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Release references to technologies held by rfkill during cleanup.
On 10/22/2014 03:14 AM, Patrik Flykt wrote:
So it seems ConnMan is not doing the technology_put() cleanup in the
correct place. As you noticed this currently happens only in
__connman_technology_remove(), and not on shutdown where only
free_rfkill() is called. So the code starting with the line technology
= technology_find(type); in __connman_technology_remove() should
actually happen in free_rfkill() instead. That way no matter what frees
up an rfkill structure also causes a technology_put() where the last one
sends off a TechnologRemoved signal before destroying the technology
structure.
I tried this suggestion, but it does not fix the problem I was trying to
fix. rfkill_list is destroyed in __connman_technology_cleanup which
happens long after plugins are cleaned up. This means most if not all
technologies have already been destroyed (possibly without being
properly released/removed) before we get to this point.
Based on your other reply though, it sounds like I need to fix my UI. I
did not consider the case of a connman crash, which would be a good
thing to handle. Also, there is the Released DBus signal that I was
overlooking.
Here is the patch of what I did to implement your suggestion.
--- connman-1.26.orig/src/technology.c
+++ connman-1.26/src/technology.c
@@ -364,13 +364,6 @@ bool connman_technology_get_wifi_tetheri
return true;
}
-static void free_rfkill(gpointer data)
-{
-struct connman_rfkill *rfkill = data;
-
-g_free(rfkill);
-}
-
static void technology_load(struct connman_technology *technology)
{
GKeyFile *keyfile;
@@ -1764,18 +1757,26 @@ int __connman_technology_remove_rfkill(u
g_hash_table_remove(rfkill_list, GINT_TO_POINTER(index));
-technology = technology_find(type);
-if (!technology)
-return -ENXIO;
+return 0;
+}
-technology_apply_rfkill_change(technology,
-technology-softblocked, !technology-hardblocked, false);
+static void free_rfkill(gpointer data)
+{
+struct connman_rfkill *rfkill = data;
+struct connman_technology *technology;
-technology_put(technology);
+technology = technology_find(rfkill-type);
+if (technology) {
+technology_apply_rfkill_change(technology,
+technology-softblocked, !technology-hardblocked, false);
-return 0;
+technology_put(technology);
+}
+
+g_free(rfkill);
}
+
int __connman_technology_init(void)
{
DBG();
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] Add support for PANU and GN roles to Bluetooth.
---
plugins/bluetooth.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 82217d0..29e828d 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -36,7 +36,9 @@
#define BLUEZ_SERVICE org.bluez
#define BLUEZ_PATH /org/bluez
+#define BLUETOOTH_PAN_PANU
1115--1000-8000-00805f9b34fb
#define BLUETOOTH_PAN_NAP
1116--1000-8000-00805f9b34fb
+#define BLUETOOTH_PAN_GN
1117--1000-8000-00805f9b34fb
#define BLUETOOTH_ADDR_LEN 6
@@ -50,6 +52,7 @@ struct bluetooth_pan {
struct connman_network *network;
GDBusProxy *btdevice_proxy;
GDBusProxy *btnetwork_proxy;
+ const char *pan_role;
};
static void address2ident(const char *address, char *ident)
@@ -85,28 +88,32 @@ static bool proxy_get_bool(GDBusProxy *proxy, const
char *property)
return value;
}
-static bool proxy_get_nap(GDBusProxy *proxy)
+static const char* proxy_get_role(GDBusProxy *proxy)
{
DBusMessageIter iter, value;
if (!proxy)
- return false;
+ return NULL;
if (!g_dbus_proxy_get_property(proxy, UUIDs, iter))
-return false;
+ return NULL;
dbus_message_iter_recurse(iter, value);
while (dbus_message_iter_get_arg_type(value) ==
DBUS_TYPE_STRING) {
const char *uuid;
dbus_message_iter_get_basic(value, uuid);
+if (strcmp(uuid, BLUETOOTH_PAN_PANU) == 0)
+ return panu;
if (strcmp(uuid, BLUETOOTH_PAN_NAP) == 0)
-return true;
+ return nap;
+if (strcmp(uuid, BLUETOOTH_PAN_GN) == 0)
+ return gn;
dbus_message_iter_next(value);
}
-return false;
+ return NULL;
}
static int bluetooth_pan_probe(struct connman_network *network)
@@ -225,9 +232,11 @@ static void pan_connect_cb(DBusMessage *message,
void *user_data)
static void pan_connect_append(DBusMessageIter *iter,
void *user_data)
{
- const char *role = BLUETOOTH_PAN_NAP;
+ const char *path = user_data;
+ struct bluetooth_pan *pan;
- dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, role);
+ pan = g_hash_table_lookup(networks, path);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, pan-pan_role);
}
static int bluetooth_pan_connect(struct connman_network *network)
@@ -322,8 +331,10 @@ static void btnetwork_property_change(GDBusProxy
*proxy, const char *name,
static void pan_create_nap(struct bluetooth_pan *pan)
{
struct connman_device *device;
+ const char* role;
- if (!proxy_get_nap(pan-btdevice_proxy)) {
+ role = proxy_get_role(pan-btdevice_proxy);
+ if (!role) {
pan_remove_nap(pan);
return;
}
@@ -366,6 +377,7 @@ static void pan_create_nap(struct bluetooth_pan *pan)
connman_network_set_group(pan-network, ident);
}
+ pan-pan_role = role;
connman_device_add_network(device, pan-network);
if (pan_connect(pan, NULL))
@@ -376,7 +388,7 @@ static void btdevice_property_change(GDBusProxy
*proxy, const char *name,
DBusMessageIter *iter, void *user_data)
{
struct bluetooth_pan *pan;
- bool pan_nap = false;
+ const char* pan_role = NULL;
if (strcmp(name, UUIDs) != 0)
return;
@@ -387,12 +399,12 @@ static void btdevice_property_change(GDBusProxy
*proxy, const char *name,
if (pan-network
connman_network_get_device(pan-network))
- pan_nap = true;
+ pan_role = pan-pan_role;
- DBG(network %p network nap %d proxy nap %d, pan-network, pan_nap,
- proxy_get_nap(pan-btdevice_proxy));
+ DBG(network %p network role %s proxy role %s, pan-network, pan_role,
+ proxy_get_role(pan-btdevice_proxy));
- if (proxy_get_nap(pan-btdevice_proxy) == pan_nap)
+ if (strcmp(proxy_get_role(pan-btdevice_proxy), pan_role) == 0)
return;
pan_create_nap(pan);
@@ -447,7 +459,7 @@ static void pan_create(GDBusProxy *network_proxy)
g_dbus_proxy_set_property_watch(pan-btdevice_proxy,
btdevice_property_change, NULL);
- DBG(pan %p %s nap %d, pan, path, proxy_get_nap(pan-btdevice_proxy));
+ DBG(pan %p %s role %s, pan, path,
proxy_get_role(pan-btdevice_proxy));
pan_create_nap(pan);
}
@@ -756,7 +768,7 @@ static void device_create(GDBusProxy *proxy)
powered = proxy_get_bool(proxy, Powered);
connman_device_set_powered(device, powered);
- if (proxy_get_nap(proxy) !bluetooth_tethering)
+ if (proxy_get_role(proxy) != NULL
[PATCH] Release references to technologies held by rfkill during cleanup.
---
src/connman.h| 1 +
src/rfkill.c | 2 ++
src/technology.c | 15 +++
3 files changed, 18 insertions(+)
diff --git a/src/connman.h b/src/connman.h
index da01215..bab013b 100644
--- a/src/connman.h
+++ b/src/connman.h
@@ -826,6 +826,7 @@ void __connman_service_save(struct connman_service
*service);
#include connman/notifier.h
+void __connman_technology_cleanup_rfkill(void);
int __connman_technology_init(void);
void __connman_technology_cleanup(void);
diff --git a/src/rfkill.c b/src/rfkill.c
index 960cfea..2f073a9 100644
--- a/src/rfkill.c
+++ b/src/rfkill.c
@@ -232,4 +232,6 @@ void __connman_rfkill_cleanup(void)
g_io_channel_unref(channel);
channel = NULL;
+
+ __connman_technology_cleanup_rfkill();
}
diff --git a/src/technology.c b/src/technology.c
index d80d9e6..5917c59 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -1776,6 +1776,21 @@ int __connman_technology_remove_rfkill(unsigned
int index,
return 0;
}
+gboolean find_first(gpointer key, gpointer value, gpointer user_data)
+{
+ return TRUE;
+}
+
+void __connman_technology_cleanup_rfkill(void)
+{
+ struct connman_rfkill *rfkill;
+
+ DBG();
+
+ while (rfkill = g_hash_table_find(rfkill_list, find_first, NULL))
+ __connman_technology_remove_rfkill(rfkill-index, rfkill-type);
+}
+
int __connman_technology_init(void)
{
DBG();
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Release references to technologies held by rfkill during cleanup.
I have written a UI for connman an ran into an bug when restarting connman. When restarting, most technologies send the TechnologyRemoved signal via DBus. Bluetooth, however, never sent this signal, so when connman restarted I had two bluetooth technology entries in my UI. I traced it down to the fact that the rfkill_list in technology.c is static and never releases the technology by calling put_technology when cleaning up. So, this patch removes all rfkills in the list on cleanup so that all of the technologies are removed. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
