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,
On Tue, Mar 31, 2009 at 8:29 AM, Florian Philipp <[email protected]> wrote:
> 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.
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
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==
Hi Bastien,
On Fri, Apr 17, 2009, Bastien Nocera wrote:
>On Fri, 2009-04-17 at 09:46 -0300, Luiz Augusto von Dentz wrote:
>> Hi,
>>
>> On Thu, Apr 16, 2009 at 10:47 PM, Xu, Martin <[email protected]> wrote:
>> >>I know the way you mentioned, but this way has some issue. You know there is >a time interval between AdapterAdded and DeviceCreated.
>> > 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.
>>
>> 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.
>
>Does this mean I can remove the work-arounds in gnome-bluetooth, to
>check for the "Powered" property change before enumerating the devices?
Yes, it should mean just that.
Johan
On Fri, 2009-04-17 at 09:46 -0300, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Thu, Apr 16, 2009 at 10:47 PM, Xu, Martin <[email protected]> wrote:
> >>I know the way you mentioned, but this way has some issue. You know there is >a time interval between AdapterAdded and DeviceCreated.
> > 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.
>
> 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.
Does this mean I can remove the work-arounds in gnome-bluetooth, to
check for the "Powered" property change before enumerating the devices?
Hi,
On Thu, Apr 16, 2009 at 10:47 PM, Xu, Martin <[email protected]> wrote:
>>I know the way you mentioned, but this way has some issue. You know there is >a time interval between AdapterAdded and DeviceCreated.
> 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.
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
>I know the way you mentioned, but this way has some issue. You know there is >a time interval between AdapterAdded and DeviceCreated.
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
>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.
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
Hi,
On Thu, Apr 16, 2009 at 5:49 AM, Xu, Martin <[email protected]> wrote:
> 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.
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
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.
diff --git a/src/adapter.c b/src/adapter.c
index 44a93b1..c096375 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -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);
Luiz Augusto von Dentz schrieb:
> Hi Florian
>
> On Thu, Apr 2, 2009 at 3:02 AM, Florian Philipp <[email protected]> wrote:
>> Florian Philipp schrieb:
>>> 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.
>>>
>> I'd also be happy about a response like 'It should work'. Then I could
>> start searching for unlogical explanations.
>
> 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.
>
>
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 Florian
On Thu, Apr 2, 2009 at 3:02 AM, Florian Philipp <[email protected]> wrote:
> Florian Philipp schrieb:
>> 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.
>>
>
> I'd also be happy about a response like 'It should work'. Then I could
> start searching for unlogical explanations.
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
Florian Philipp schrieb:
> Luiz Augusto von Dentz schrieb:
>> Hi Florian,
>>
>> On Tue, Mar 31, 2009 at 8:29 AM, Florian Philipp <[email protected]> wrote:
>>> 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.
> [...]
>> 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,
>>
>
> 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.
>
I'd also be happy about a response like 'It should work'. Then I could
start searching for unlogical explanations.
Luiz Augusto von Dentz schrieb:
> Hi Florian,
>
> On Tue, Mar 31, 2009 at 8:29 AM, Florian Philipp <[email protected]> wrote:
>> 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.
>
[...]
> 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,
>
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.