PAN with bluez-utils-3

Hi list!

I used to have a working private area network (pan) over bluetooth. However, since the update to bluez-utils-3.36, it doesn't work anymore.

I especially want to get rid of the old daemons because, as I understand it, they are deprecated. However, I just can't find satisfying documentation on the new structure and config files.

I don't want to go into detail on what exactly doesn't work at the moment because I really just guessed how I had to configure everything.

So my question is: Does anyone have a working set of configuration files for newer bluez-utils? Preferably something related to the roles GN or NAP.

Thanks in advance!
Florian Philipp

Hi Florian,

Check the documentation under doc/network-api.txt, it should be very simple to detect if the remote device supports PAN it will export org.bluez.Network on its dbus object. Now if your application doesn't support introspection you can detect it by using the UUIDs property exported in the very same dbus object I had mentioned.

For actually connecting to the device you will only need to call org.bluez.Network.Connect({"panu","gn","nap"...}) , you can tell bluetoothd to run a script of your choice when the connection is activated by editing network.conf. Note that some daemons like NetworkManager and connman should not require any script.

To act like a server you don't need to do anything for panu, for gn we normally create a bridge called pan0 where all client are added, nap is especial because of the routing stuff so you/your system need to configure a bridge properly and make network.conf to use it (by default this should be pan1).

Now if you got any problem you could please provide a more detailed info of it, if it is a bug we will be happy to fix it.

Thanks,

Luiz Augusto von Dentz
Engenheiro de Computação

[...]

Thanks for your answer! I don't think it's bug but merely lack of understanding on my part. Therefore I'll go into detail now:

Here I have a Gentoo system which shall act as the GN. Its hcid.conf looks like this:"

options {
	autoinit yes;
	security auto;
	pairing multi;
	passkey "123456";
}
device {
 	name "BlueZ (%d) at %h";
	class 0x020100;
	iscan enable; pscan enable;
	lm master;
	lp rswitch,hold,sniff,park;
}

"

Its network.conf would then look like this (?):"
[General]

[PANU Role]
Autostart=false

[GN Role]
Interface=blue0
Autostart=true

[NAP Role]
Autostart=false
"

The init-script executes the following command:
/usr/sbin/hcid -s -f /etc/bluetooth/hcid.conf

What's wrong with this? When I test it with Windows clients, they fiind the device but it doesn't appear to have PAN functionality.

P.S.: Sorry Luiz if I accidentally sent the reply directly to you at first.

I'd also be happy about a response like 'It should work'. Then I could start searching for unlogical explanations.

Hi Florian

It looks like you have been using BlueZ 3.x series which is way too old for me to take a look. Check with 4.x if it helps.

Luiz Augusto von Dentz
Engenheiro de Computação

This thread is a bit old, I know. I just wanted to say: Nevermind.

It seems that the new versions don't support my use case as good as the 2.x-series did (no default pin without a graphical interface or a self-made helper program, for one thing). Besides, there is - at least for me - a big lack of documentation on how things should be configured.

In any case, upgrading to 3.x and to an even higher degree 4.x caused too much work for a thing that used to just work.

Therefore I decided to go back to 2.25 and they there for the near future.

Hi:
I found that at bluez CreatDevice signal is not emitted at function create_stored_device_from_profile() in src/adapter.c.
That leads to system can not got the CreatDevice singal when the deivce is created though storage. The usage case is that, when I unplug the bluethooth usb dongle and then plug in again. System can not get the CreatDevice signal. So ConnMan can not handle the CreatDevice signal. I have created patch to bluez to fix the issue. Please review, any comments are welcome.

index 44a93b1..c096375 100644
@@ -1867,6 +1867,7 @@ static void create_stored_device_from_profiles(char *key, char *value,
 	struct btd_device *device;
 	bdaddr_t dst;
 	char srcaddr[18], dstaddr[18];
+	const char *path;
 
 	ba2str(&adapter->bdaddr, srcaddr);
 

@@ -1877,6 +1878,12 @@ static void create_stored_device_from_profiles(char *key, char *value,
 	device = device_create(connection, adapter, key);
 	if (!device)
 		return;
+
+	path = device_get_path(device);
+	g_dbus_emit_signal(connection, adapter->path,
+				ADAPTER_INTERFACE, "DeviceCreated",
+				DBUS_TYPE_OBJECT_PATH, &path,
+				DBUS_TYPE_INVALID);
 
 	device_set_temporary(device, FALSE);
 	adapter->devices = g_slist_append(adapter->devices, device);

Hi,

IMO the correct way of doing it is to via AdapterAdded signal and then GetProperties, which in most cases is what you really should do to discover all devices. If you make stored devices to emit signals you will probably just slow down the boot.

Luiz Augusto von Dentz
Engenheiro de Computação

I know the way you mentioned, but this way has some issue. You know there is a time interval between AdapterAdded and DeviceCreated. So on ConnMann when I get AdapterAdded signal and try to use GetProperties to get the device, I found that the Device Array is empty, because at that time the Device has not been created. So no further DeviceCreated signle, ConnMan can not handle the DeviceCreated event any more. I do not think that send a signal will effect the boot time greatly.
_______________________________________________
connman mailing list
[email protected]
https://lists.moblin.org/mailman/listinfo/connman

I found that the time interval on my machine is about 230 milliseconds. The time is enough to schedule out to other process to handle the AdapterAdded signal.
_______________________________________________
connman mailing list
[email protected]
https://lists.moblin.org/mailman/listinfo/connman

Hi,

There is a fix for this race condition already on git, release 4.36 will be shipped with it. AdapterAdded is now emitted when adapter properties are "ready", the problem was that we need the adapter address for accessing the storage but that is only available when receiving DEVUP event but we were actually emitting AdapterAdded before when handling DEVREG event. The interval you mentioned is probably the interval between DEVREG and DEVUP, with the fix it shouldn't happen anymore since AdapterAdded will only be triggered by the very first DEVUP to that device.

Luiz Augusto von Dentz
Engenheiro de Computação

Does this mean I can remove the work-arounds in gnome-bluetooth, to check for the "Powered" property change before enumerating the devices?

Hi Bastien,

Yes, it should mean just that.

Johan

VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLg0KSSB3aWxsIHRyeSByZWxlYXNlIDQuMzYgd2hlbmNl IHlvdSByZWxlYXNlIGl0Lg0KSWYgaXQgZG9lcyB3b3JrLCB0aGVuIHdlIG5lZWQgbm90IGNoYW5n ZSBhbnl0aGluZyBhdCBjb21tb24gc2lkZS4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBjb25ubWFuLWJvdW5jZXNAbW9ibGluLm9yZyBbbWFpbHRvOmNvbm5tYW4tYm91bmNl c0Btb2JsaW4ub3JnXSBPbiBCZWhhbGYgT2YgTHVpeiBBdWd1c3RvIHZvbiBEZW50eg0KU2VudDog MjAwOeW5tDTmnIgxN+aXpSAyMDo0Nw0KVG86IGNvbm5tYW5AbW9ibGluLm9yZw0KQ2M6IFlpbiwg S2FuZ2thaTsgbGludXgtYmx1ZXRvb3RoQHZnZXIua2VybmVsLm9yZzsgTGl1LCBCaW5nIFdlaTsg R2FvLCBCaW4NClN1YmplY3Q6IFJlOiBbY29ubm1hbl0gQ3JlYXREZXZpY2Ugc2lnbmFsIHNob3Vs ZCBiZSBlbWl0dGVkIGF0IGZ1bmN0aW9uIGNyZWF0ZV9zdG9yZWRfZGV2aWNlX2Zyb21fcHJvZmls ZXMoKSBpbiBzcmMvYWRhcHRlci5jDQoNCkhpLA0KDQpPbiBUaHUsIEFwciAxNiwgMjAwOSBhdCAx MDo0NyBQTSwgWHUsIE1hcnRpbiA8bWFydGluLnh1QGludGVsLmNvbT4gd3JvdGU6DQo+Pkkga25v dyB0aGUgd2F5IHlvdSBtZW50aW9uZWQsIGJ1dCB0aGlzIHdheSBoYXMgc29tZSBpc3N1ZS4gWW91 IGtub3cgdGhlcmUgaXMgPmEgdGltZSBpbnRlcnZhbCBiZXR3ZWVuIEFkYXB0ZXJBZGRlZCBhbmQg RGV2aWNlQ3JlYXRlZC4NCj4gSSBmb3VuZCB0aGF0IHRoZSB0aW1lIGludGVydmFsIG9uIG15IG1h Y2hpbmUgaXMgYWJvdXQgMjMwIG1pbGxpc2Vjb25kcy4gVGhlIHRpbWUgaXMgZW5vdWdoIHRvIHNj aGVkdWxlIG91dCB0byBvdGhlciBwcm9jZXNzIHRvIGhhbmRsZSB0aGUgQWRhcHRlckFkZGVkIHNp Z25hbC4NCg0KVGhlcmUgaXMgYSBmaXggZm9yIHRoaXMgcmFjZSBjb25kaXRpb24gYWxyZWFkeSBv biBnaXQsIHJlbGVhc2UgNC4zNg0Kd2lsbCBiZSBzaGlwcGVkIHdpdGggaXQuIEFkYXB0ZXJBZGRl ZCBpcyBub3cgZW1pdHRlZCB3aGVuIGFkYXB0ZXINCnByb3BlcnRpZXMgYXJlICJyZWFkeSIsIHRo ZSBwcm9ibGVtIHdhcyB0aGF0IHdlIG5lZWQgdGhlIGFkYXB0ZXINCmFkZHJlc3MgZm9yIGFjY2Vz c2luZyB0aGUgc3RvcmFnZSBidXQgdGhhdCBpcyBvbmx5IGF2YWlsYWJsZSB3aGVuDQpyZWNlaXZp bmcgREVWVVAgZXZlbnQgYnV0IHdlIHdlcmUgYWN0dWFsbHkgZW1pdHRpbmcgQWRhcHRlckFkZGVk DQpiZWZvcmUgd2hlbiBoYW5kbGluZyBERVZSRUcgZXZlbnQuIFRoZSBpbnRlcnZhbCB5b3UgbWVu dGlvbmVkIGlzDQpwcm9iYWJseSB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBERVZSRUcgYW5kIERFVlVQ LCB3aXRoIHRoZSBmaXggaXQNCnNob3VsZG4ndCBoYXBwZW4gYW55bW9yZSBzaW5jZSBBZGFwdGVy QWRkZWQgd2lsbCBvbmx5IGJlIHRyaWdnZXJlZCBieQ0KdGhlIHZlcnkgZmlyc3QgREVWVVAgdG8g dGhhdCBkZXZpY2UuDQoNCi0tIA0KTHVpeiBBdWd1c3RvIHZvbiBEZW50eg0KRW5nZW5oZWlybyBk ZSBDb21wdXRhw6fDo28NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpjb25ubWFuIG1haWxpbmcgbGlzdA0KY29ubm1hbkBtb2JsaW4ub3JnDQpodHRwczov L2xpc3RzLm1vYmxpbi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb25ubWFuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpjb25ubWFuIG1haWxpbmcgbGlzdApj b25ubWFuQG1vYmxpbi5vcmcKaHR0cHM6Ly9saXN0cy5tb2JsaW4ub3JnL21haWxtYW4vbGlzdGlu Zm8vY29ubm1hbg==