hci_scodata_packet: hci0 SCO packet for unknown connection handle 1

I'm running Ubuntu Hardy, so I have a nice bleeding edge installation of kernel and bluez tools. I am trying to get a Jabra headset to work but it's just not happening for me. I plug in the dongle and get the little bluetooth applet showing in my taskbar. My headset also beeps when this happens.

lsusb reports:

Bus 001 Device 009: ID 0a5c:2121 Broadcom Corp.

lsbusb -v reports:

Bus 001 Device 009: ID 0a5c:2121 Broadcom Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a5c Broadcom Corp.
idProduct 0x2121
bcdDevice 1.00

  iManufacturer           1 Broadcom Corp
  iProduct                2 BCM92045B3 ROM
  iSerial                 0 
  bNumConfigurations      1

...

I believe it's all paired up nicely:

$ hcitool con
Connections:
	> ACL 00:1A:45:1B:19:89 handle 11 state 1 lm SLAVE AUTH ENCRYPT SECURE 

I follow the steps in http://wiki.bluez.org/wiki/HOWTO/AudioDevices but when I try to play something with:

$ sox /mnt/mp3/bad_mouth.wav -t wav -c 1 - | aplay -D plug:bluetooth
sox wav: Length in output .wav header will be wrong since can't seek to fix it
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono

I hear nothing and the dmesg/console log shows:

Feb 23 20:05:48 pc kernel: [20205.288394] Bluetooth: L2CAP ver 2.9
Feb 23 20:05:48 pc kernel: [20205.288405] Bluetooth: L2CAP socket layer initialized
Feb 23 20:05:48 pc kernel: [20205.297727] Bluetooth: RFCOMM socket layer initialized
Feb 23 20:05:48 pc kernel: [20205.297748] Bluetooth: RFCOMM TTY layer initialized
Feb 23 20:05:48 pc kernel: [20205.297750] Bluetooth: RFCOMM ver 1.8
Feb 23 20:06:37 pc kernel: [20254.100422] Bluetooth: SCO (Voice Link) ver 0.5
Feb 23 20:06:37 pc kernel: [20254.100431] Bluetooth: SCO socket layer initialized
Feb 23 20:06:37 pc kernel: [20254.788127] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.798114] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.798118] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.798121] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.808103] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.808107] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.808110] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1
Feb 23 20:06:37 pc kernel: [20254.818100] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1

[ and on and on and on ]

Anyone got any advise?

Thanx,
b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Brian

I've added the kernel patch that is supposed to handle this problem to the end of the wiki page. Please let us know if it helps. It's ostensibly going to be an issue if you have a bluetooth adapter capable of esco but your headset is not.

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Hi Brad,

Is this something that can go upstream easily?

I tend to avoid patching and building kernels since I tend to follow a distribution's development version (i.e. currently Ubuntu Hardy) which means high kernel turnover, which means I spend too much time patching and building kernels if I maintain a patch (series) outside of the vendor's kernel.

Perhaps I can convince Ubuntu to roll this patch in. If it's hoped to be accepted upstream that might be possible. If it's been rejected upstream for whatever reason, Ubuntu probably won't let it in either.

How do I determine if this is the case? Just to see if we are barking up the right tree?

Thanx!

b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Hi Brad,

the patch you sent me is fully broken. First of all the coding style is wrong. Does nobody have learned this by now? I always look for that first before even reading the patch. Second the case where an ESCO_LINK returns NULL is broken and will fall over and crash.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users