* [Bluez-users] Use an ACL link when an SCO link is established
@ 2006-10-04 19:12 Michel Leconte
2006-10-04 20:29 ` Marcel Holtmann
0 siblings, 1 reply; 2+ messages in thread
From: Michel Leconte @ 2006-10-04 19:12 UTC (permalink / raw)
To: bluez-users
[-- Attachment #1.1: Type: text/plain, Size: 6761 bytes --]
Hi all,
my goal is to use an ACL link when an SCO link is established.
I work with two bluetooth development kits from Semtech-Xemics (SE1441).
They are compliant Bluetooth v1.2. For the following explanations, one kit is noted "A" and the other "B".
1) First, I create an ACL link between "A" and "B" with : hcitool cc BD_ADDR of "B",
2) Once the ACL link is done, "A" execute an "HCI_Setup_Synchronous_Connection" command to "B",
3) At the event of an SCO request connection, "B" respond with an "HCI_Accept_Synchronous_Connection_Request" command.
4) When the SCO link is established, a "Synchronous Connection Complete" HCI event is visible from the hci layer of each kit.
the "hcitool con" gives :
> SCO AA:AA:AA:AA:AA:04 handle 0 state 5 lm SLAVE
> ACL AA:AA:AA:AA:AA:04 handle 0 state 1 lm SLAVE
5) I try to use the ACL link with a l2ping command from B to A
the l2ping command gives :
l2ping AA:AA:AA:AA:AA:04 (BD_ADDR of A)
Ping: AA:AA:AA:AA:AA:04 from AA:AA:AA:AA:AA:05 (data size 44) ...
no response from AA:AA:AA:AA:AA:04: id 0
no response from AA:AA:AA:AA:AA:04: id 1
---------------------------------------------------------------------------------------------------------------------
Question 1 : With this configuration (SCO and ACL links between A and B), why l2ping doesn't work ?
The ACL link can be used isn't it ?
Question 2 : From the hci dump of each side, I notice that there is a difference between the information
of the command and the OGF and OCF between the parenthesises. See below the hcidump results, the
red lines are those which give me a problem. At the "A" side, I send an "HCI_Setup_Asynchronous_Connection" and hcidump indicates an "HCI_Accept_Synchronous_Connection". I get a similar problem in "B" side an "HCI_Reject_Synchronous_Connection " instead of an " HCI_Accept_Synchronous_Connection ".
When you see the bluetooth spec :
HCI_Setup_Asynchronous_Connection is OGF=0x01 and OCF=0x28
HCI_Accept_Synchronous_Connection is OGF=0x01 and OCF=0x29
HCI_Reject_Synchronous_Connection is OGF=0x01 and OCF=0x2A
Do these differences are benign for the bluez stack or they can be the origine
of my problem ??
************************** HCI dump from "A" ***********************************************
HCI sniffer - Bluetooth packet analyzer ver 1.30
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr AA:AA:AA:AA:AA:05 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 0 bdaddr AA:AA:AA:AA:AA:05 type ACL encrypt 0x00
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
handle 0 policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Command Complete (0x0e) plen 6
Write Link Policy Settings (0x02|0x000d) ncmd 1
status 0x00 handle 0
< HCI Command: Accept Synchronous Connection (0x01|0x0028) plen 17
handle 0
40 1F 00 00 40 1F 00 00 FF FF C1 01 00 04 00
> HCI Event: Max Slots Change (0x1b) plen 3
handle 0 slots 5
> HCI Event: Command Status (0x0f) plen 4
Accept Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x00 handle 256 bdaddr AA:AA:AA:AA:AA:05 type SCO
Air mode: u-law log
************************** HCI dump from "B" ***********************************************
HCI sniffer - Bluetooth packet analyzer ver 1.30
device: hci0 snap_len: 1028 filter: 0xffffffff
> HCI Event: Connect Request (0x04) plen 10
bdaddr AA:AA:AA:AA:AA:04 class 0x3e0100 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr AA:AA:AA:AA:AA:04 role 0x01
Role: Slave
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 0 bdaddr AA:AA:AA:AA:AA:04 type ACL encrypt 0x00
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
handle 0 policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Command Complete (0x0e) plen 6
Write Link Policy Settings (0x02|0x000d) ncmd 1
status 0x00 handle 0
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
handle 0 ptype 0xcc18
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
status 0x00 handle 0 ptype 0x0018
Packet type: DM1 DH1
> HCI Event: Connect Request (0x04) plen 10
bdaddr AA:AA:AA:AA:AA:04 class 0x3e0100 type SCO
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr AA:AA:AA:AA:AA:04 role 0x01
Role: Slave
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
< HCI Command: Reject Synchronous Connection (0x01|0x0029) plen 21
bdaddr AA:AA:AA:AA:AA:04
FF FF FF FF FF FF FF FF FF FF C1 01 FF 04 00
> HCI Event: Command Status (0x0f) plen 4
Reject Synchronous Connection (0x01|0x0029) status 0x00 ncmd 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x00 handle 256 bdaddr AA:AA:AA:AA:AA:04 type SCO
Air mode: u-law log
Question 3 : The event "Synchronous Connect Complete" gives the handle of the SCO link
in my case the handle value is 256. But when you see upside the hcitool
con result gives a handle 0 ? Is it normal ?
Question 4 : Here's my software configurations : hcidump 1.30 bluez-libs-2.25 bluez-utils-2.25 linux-debian 2.6.12.2 with an ARM target
As I have to keep the kernel 2.6.12.2, with wich higher version of bluez-libs, bluez-utils and hcidump can I use to be compliant with my kernel ?
Thanks to all for any suggestions..
warm regards
Michel
---------------------------------------------------------------------------------------------------------------------
the result of an "hciconfig -a" is :
hci0: Type: UART
BD Address: AA:AA:AA:AA:AA:04 ACL MTU: 339:8 SCO MTU: 180:8
UP RUNNING PSCAN ISCAN
RX bytes:522 acl:0 sco:0 events:61 errors:0
TX bytes:1367 acl:15 sco:0 commands:26 errors:0
Features: 0xff 0xff 0xbd 0xf8 0x1b 0x18 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'BlueZ (0)'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0x0 LMP Ver: 1.2 (0x2) LMP Subver: 0xc
Manufacturer: Newlogic (23)
---------------------------------------------------------------------------------------------------------------------------
[-- Attachment #1.2: Type: text/html, Size: 8920 bytes --]
[-- Attachment #2: Type: text/plain, Size: 348 bytes --]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bluez-users] Use an ACL link when an SCO link is established
2006-10-04 19:12 [Bluez-users] Use an ACL link when an SCO link is established Michel Leconte
@ 2006-10-04 20:29 ` Marcel Holtmann
0 siblings, 0 replies; 2+ messages in thread
From: Marcel Holtmann @ 2006-10-04 20:29 UTC (permalink / raw)
To: BlueZ users
Hi Michel,
>
> my goal is to use an ACL link when an SCO link is established.
>
> I work with two bluetooth development kits from Semtech-Xemics
> (SE1441).
>
> They are compliant Bluetooth v1.2. For the following explanations, one
> kit is noted "A" and the other "B".
>
> 1) First, I create an ACL link between "A" and "B" with : hcitool cc
> BD_ADDR of "B",
first of all, don't do this. The "hcitool cc ..." is for testing only
and doesn't honor the kernel internal reference counting. You will see
side effects and I am not going to help you with it.
>
> 2) Once the ACL link is done, "A" execute an
> "HCI_Setup_Synchronous_Connection" command to "B",
>
> 3) At the event of an SCO request connection, "B" respond with an
> "HCI_Accept_Synchronous_Connection_Request" command.
>
> 4) When the SCO link is established, a "Synchronous Connection
> Complete" HCI event is visible from the hci layer of each kit.
>
> the "hcitool con" gives :
>
> > SCO AA:AA:AA:AA:AA:04 handle 0 state 5 lm SLAVE
>
> > ACL AA:AA:AA:AA:AA:04 handle 0 state 1 lm SLAVE
The eSCO support inside the kernel has never been adapted. You need to
change the kernel to open and accept eSCO connections.
>
> 5) I try to use the ACL link with a l2ping command from B to A
>
> the l2ping command gives :
>
> l2ping AA:AA:AA:AA:AA:04 (BD_ADDR of A)
>
> Ping: AA:AA:AA:AA:AA:04 from AA:AA:AA:AA:AA:05 (data size 44) ...
>
> no response from AA:AA:AA:AA:AA:04: id 0
>
> no response from AA:AA:AA:AA:AA:04: id 1
l2ping will create the ACL link if needed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Question 1 : With this configuration (SCO and ACL links between A and
> B), why l2ping doesn't work ?
>
> The ACL link can be used isn't it ?
Sure. But let the kernel create it. As I said, l2ping will create its
needed ACL link by itself.
>
> Question 2 : From the hci dump of each side, I notice that there is a
> difference between the information
>
> of the command and the OGF and OCF between the parenthesises. See
> below the hcidump results, the
>
> red lines are those which give me a problem. At the "A" side, I send
> an "HCI_Setup_Asynchronous_Connection" and hcidump indicates an
> "HCI_Accept_Synchronous_Connection". I get a similar problem in "B"
> side an "HCI_Reject_Synchronous_Connection " instead of an "
> HCI_Accept_Synchronous_Connection ".
This might be an off-by-one bug in hcidump. Check the hcidump source
code and send in a patch for it.
>
> When you see the bluetooth spec :
>
> HCI_Setup_Asynchronous_Connection is OGF=0x01 and OCF=0x28
>
> HCI_Accept_Synchronous_Connection is OGF=0x01 and OCF=0x29
>
> HCI_Reject_Synchronous_Connection is OGF=0x01 and OCF=0x2A
>
>
>
> Do these differences are benign for the bluez stack or they can be the
> origine
>
> of my problem ??
The hcidump is stupid and has nothing to do with actual data send to the
chip. This looks like a decoding bug. Or you simply sent the wrong
command. I haven't checked the specification.
> Question 3 : The event "Synchronous Connect Complete" gives the handle
> of the SCO link
>
> in my case the handle value is 256. But when you see upside the
> hcitool
>
> con result gives a handle 0 ? Is it normal ?
Depends on the hardware you use. The handle is 16 bit value and the chip
implementation can at least pick the first 12 bits as it wishes.
>
> Question 4 : Here's my software configurations : hcidump 1.30
> bluez-libs-2.25 bluez-utils-2.25 linux-debian 2.6.12.2 with an ARM
> target
>
>
>
> As I have to keep the kernel 2.6.12.2, with wich higher version of
> bluez-libs, bluez-utils and hcidump can I use to be compliant with my
> kernel ?
The 3.x userspace packages will work with that kernel.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-10-04 20:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-04 19:12 [Bluez-users] Use an ACL link when an SCO link is established Michel Leconte
2006-10-04 20:29 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox