Hi,
I appreciate your great work and dedication to the bluetooth technologie.
The blueZ Stack is the most stable BT-Software i ever used on a PC-Style
Hardware and im verry happy that it is avaiable. I hope i can contribute at
some point, but i think i need to keep on learning to be able to. Heres what
i found out for now.
I have noticed that
"hcitool inq" returnes "Device or resource busy" every time if a
"hcitool info <mac>" || "sdptool search --bdaddr <mac> <someservice>" is
running on the same hciX device.
Is this normal or should this be considered a problem?
If it is normal, i would appreciate some pointer to readings that could make
me understand why this happens.
Im using:
hcitool - HCI Tool ver 2.3
sdptool - SDP Tool v1.5
kernel 2.4.23
BlueZ Core ver 2.3
BlueZ RFCOMM ver 1.1
BlueZ L2CAP ver 2.3
BlueZ HCI USB driver ver 2.4
The problem appears with both USB-BT Devices i own:
MSI PC2PC Bluetooth
[root@localhost root]# hciconfig hci0 -a
hci0: Type: USB
BD Address: 00:10:DC:E9:32:D1 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
Features: 0xff 0xff 0x0f 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'TuxBox'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
[root@localhost root]# hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:10:DC:E9:32:D1 ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.4 (bc02x)
and also a
Acer BT-600
[root@localhost root]# hciconfig hci0 -a
hci0: Type: USB
BD Address: 00:02:72:01:4C:B8 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
Features: 0xff 0xff 0x0f 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'TuxBox'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
[root@localhost root]# hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:02:72:01:4C:B8 ACL MTU: 192:8 SCO MTU: 64:8
HCI 16.4 (bc02x)
I saw some threads that discuss problems that could be similar to the one
discribed here but they all where quite old and didnt point to a solution.
Also a lot of things changed in BlueZ and the Tools so i hope im not
bothering you starting this topic again.
If any further information is needed for tracking the problem i?ll be happy
to provide it.
Greetings
Andreas Gaufer
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>>The create_connection-inquiry restriction is there because both
>>procedures need to get as much radio bandwidth as possible to work. In
>>particular, taking bandwidth away from paging can cause spurious failed
>>connections. In this case, create_connection wins. If you issue a
>>create_connection while an inquiry is in progress, we will terminate
>>the inquiry with an inquiry_complete event and start paging
>>immediately.
>
>
> this is a nice thing/feature to know. Is it documented anywhere in the
> firmware release notes?
This particular behaviour is not documented (if it were, it would be in
our HCI implementation document (bcore-me-007Pb), not the firmware
release note).
The Bluetooth baseband spec says that devices should free up as much
bandwidth as possible for inquiring and paging. It doesn't specify how
to handle a collision between two actions that both require a lot of
bandwidth.
Really, the host should cancel inquiry before trying to create a
connection. However, it would be churlish for us to design our code to
work only with perfect hosts. Where the spec allows it, a little bit of
flexibility can make things a bit easier for all concerned (not least,
by reducing the volume of support calls we get).
There are several places where we do this. Most of them are not
documented and the behaviour should not be relied on. Future versions
of the spec may mandate a particular behaviour.
If in doubt, whenever we get conflicting requests from the host, we
apply the Law of Least Astonishment [1]. Mostly this involves deciding
which course of action is going to cause least damage to the network.
We will prioritise some behaviours over others (so activities which
are essential to keeping an existing link up win over those that are
merely nice).
Naturally, we don't want to burn too much code space and processor
time dealing with things the host shouldn't be doing, so we tend to
pick simple heuristics. It's not worth trying to go for perfect
algorithms - that would require being psychic as on different
occasions the host may want different things.
Consequently, we do tend to change our minds between firmware
versions depending on what's easiest to implement and the feedback
we're getting from our customers.
From BlueZ's point of view, you need to maximise the number
Bluetooth devices you work with. You should be trying to avoid
unspecified or manufacturer specific behaviour.
- Steven
[1] http://www.schedler.org/cookie/the-tao-of-programming.html#4.0
--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
http://www.mimesweeper.com
**********************************************************************
Hi Andreas,
> >In your case, the correct response to having your inquiry rejected is
> >to back off for a few seconds and try again - either that, or find some
> >way of sharing access to the device.
>
> Sounds good to me, im actualy handling it like this. The only problem is if
> a device is in range that does not respond to the connection attemt will
> make the device unusable for inquiry until the connection attemt times out.
If the device runs an inquiry the kernel sets the HCI_INQUIRY flag. You
can check this with hciconfig.
> Who decides when to timeout? I guess the host, so where can i configure
> these timeouts?
we have timers on the host stack, but the important one is the page
timeout of the link manager. You should start reading the HCI spec. to
see what you can set on chip level. And "man hciconfig" is also very
helpful ;)
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Steven, Marcel, List,
>In your case, the correct response to having your inquiry rejected is
>to back off for a few seconds and try again - either that, or find some
>way of sharing access to the device.
Sounds good to me, im actualy handling it like this. The only problem is if
a device is in range that does not respond to the connection attemt will
make the device unusable for inquiry until the connection attemt times out.
Who decides when to timeout? I guess the host, so where can i configure
these timeouts?
Greetings
Andreas
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Steven,
> The create_connection-inquiry restriction is there because both
> procedures need to get as much radio bandwidth as possible to work. In
> particular, taking bandwidth away from paging can cause spurious failed
> connections. In this case, create_connection wins. If you issue a
> create_connection while an inquiry is in progress, we will terminate
> the inquiry with an inquiry_complete event and start paging
> immediately.
this is a nice thing/feature to know. Is it documented anywhere in the
firmware release notes?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Andreas Gaufer wrote:
> Not wokring inq:
> < HCI Command: Inquiry(0x01|0x0001) plen 5
> 33 8B 9E 08 0A
>
> >HCI Event: Command Status(0x0f) plen 4
> 0C 01 01 04
CSR firmware will issue this error code if you try to start an inquiry
while an inquiry or a create_connection is already in progress.
The inquiry-inquiry restriction is there to protect against hosts who
have lost control of what they're doing. If we accepted the second
inquiry, how many inquiry_complete events should we issue?
The create_connection-inquiry restriction is there because both
procedures need to get as much radio bandwidth as possible to work. In
particular, taking bandwidth away from paging can cause spurious failed
connections. In this case, create_connection wins. If you issue a
create_connection while an inquiry is in progress, we will terminate
the inquiry with an inquiry_complete event and start paging
immediately.
Once paging has finished and the baseband connection is complete then we
will allow the host to inquire again.
Since a Bluetooth chip is connected to one host and since the chip is
an embedded device with limited resources, we expect the host to handle
the multiplexing of requests. We expect the host's state to be
synchronised to ours - if it isn't, we're in trouble.
It is unreasonable to expect that multiple applications can issue
arbitrary HCI commands and expect the to complete as if they had sole
access to the device (consider what would happen with ACL flow control
tokens).
SDP searching and similar activities will take over the radio to inquire
and make connections. It is therefore expected that other simultaneous
actions will fail.
In your case, the correct response to having your inquiry rejected is
to back off for a few seconds and try again - either that, or find some
way of sharing access to the device.
- Steven
--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
http://www.mimesweeper.com
**********************************************************************
Hi Andreas,
> hciconfig revision tells me that both chips have HCI 16.4 (bc02x) so i
> checked hcidump -x , heres whats happening:
>
> Wokring inq:
> < HCI Command: Inquiry(0x01|0x0001) plen 5
> 33 8B 9E 08 0A
> > HCI Event: Command Status(0x0f) plen 4
> 00 01 01 04
>
> Not wokring inq:
> < HCI Command: Inquiry(0x01|0x0001) plen 5
> 33 8B 9E 08 0A
> > HCI Event: Command Status(0x0f) plen 4
> 0C 01 01 04
>
> Do i guess right when i think that the differing "0C" means "Command
> disallowed" like discribed in BT 1.2 Core Spec, Vol 2, Core System Package,
> Part D (Error Codes) ?
the error code is correct and this is a problem of the firmware on the
chip. For me this is working fine on any CSR chip with HCI 16.x.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
>this depends on your Bluetooth chip and the firmware on this chip. In
>general all CSR chips with HCI 16.x firmware should be able to run an
>inquiry while maintaining an ACL link. So your modules should not have a
>problem here, but you can run a hcidump and look for the error code that
>is returned by the inquiry command.
hciconfig revision tells me that both chips have HCI 16.4 (bc02x) so i
checked hcidump -x , heres whats happening:
Wokring inq:
< HCI Command: Inquiry(0x01|0x0001) plen 5
33 8B 9E 08 0A
> HCI Event: Command Status(0x0f) plen 4
00 01 01 04
Not wokring inq:
< HCI Command: Inquiry(0x01|0x0001) plen 5
33 8B 9E 08 0A
> HCI Event: Command Status(0x0f) plen 4
0C 01 01 04
Do i guess right when i think that the differing "0C" means "Command
disallowed" like discribed in BT 1.2 Core Spec, Vol 2, Core System Package,
Part D (Error Codes) ?
If so, would you recommend:
A: Use another BT-Device with a more recent HCI Firmware Revision.
or
B: Do inq. on one device and use another device to connect to the found
peers.
or
c: Do something else ;)
Thanks for your help, i realy appreciate it.
Greetings
Andreas Gaufer
Hi Andreas,
> I appreciate your great work and dedication to the bluetooth technologie.
> The blueZ Stack is the most stable BT-Software i ever used on a PC-Style
> Hardware and im verry happy that it is avaiable. I hope i can contribute at
> some point, but i think i need to keep on learning to be able to. Heres what
> i found out for now.
>
> I have noticed that
>
> "hcitool inq" returnes "Device or resource busy" every time if a
> "hcitool info <mac>" || "sdptool search --bdaddr <mac> <someservice>" is
> running on the same hciX device.
>
> Is this normal or should this be considered a problem?
this depends on your Bluetooth chip and the firmware on this chip. In
general all CSR chips with HCI 16.x firmware should be able to run an
inquiry while maintaining an ACL link. So your modules should not have a
problem here, but you can run a hcidump and look for the error code that
is returned by the inquiry command.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel