Bug 9871 - hci0 SCO packet for unknown connection handle 1
hci0 SCO packet for unknown connection handle 1
Status: RESOLVED OBSOLETE
Product: Drivers
Classification: Unclassified
Component: Network
All Linux
: P1 normal
Assigned To: Marcel Holtmann
:
: 10270 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-01 11:30 UTC by Adam Szalkowski
Modified: 2013-12-19 15:08 UTC (History)
11 users (show)

See Also:
Kernel Version: 2.6.31
Tree: Mainline
Regression: Yes


Attachments
Full hcidump (574.89 KB, text/plain)
2008-02-01 11:34 UTC, Adam Szalkowski
Details
syslog output (5.59 KB, text/plain)
2008-02-01 11:42 UTC, Adam Szalkowski
Details
New hcidump (34.05 KB, text/plain)
2008-02-01 12:52 UTC, Adam Szalkowski
Details
hcidump -X -V against comment #10 (958.07 KB, text/plain)
2009-03-15 08:33 UTC, rajan batra
Details

Description Adam Szalkowski 2008-02-01 11:30:17 UTC
Latest working kernel version: 2.6.22
Earliest failing kernel version: 2.6.23
Distribution: gentoo
Hardware Environment:
dongle: ANYCOM USB-250
Bus 005 Device 061: ID 0a5c:4503 Broadcom Corp. 
Bus 005 Device 060: ID 0a5c:4502 Broadcom Corp. 
Bus 005 Device 059: ID 0a5c:2111 Broadcom Corp. 
Bus 005 Device 058: ID 0a5c:4500 Broadcom Corp. 

hci0:	Type: USB
	BD Address: 00:16:38:3A:67:60 ACL MTU: 1017:8 SCO MTU: 64:1
	UP RUNNING PSCAN 
	RX bytes:972 acl:0 sco:0 events:27 errors:0
	TX bytes:357 acl:0 sco:0 commands:27 errors:0
	Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: SLAVE ACCEPT 
	Name: 'Gentoo (0)'
	Class: 0x080104
	Service Classes: Capturing
	Device Class: Computer, Desktop workstation
	HCI Ver: 2.0 (0x3) HCI Rev: 0x217c LMP Ver: 2.0 (0x3) LMP Subver: 0x41e0
	Manufacturer: Broadcom Corporation (15)

Software Environment:
alsa-lib-1.0.15, bluez-utils-3.24, headset installed as pcm device (type bluetooth) in asound.conf

Problem Description:

When starting to play sound over bluetooth headset syslog gets filled with:
"hci_scodata_packet: hci0 SCO packet for unknown connection handle 1"

Steps to reproduce:
- plug in dongle
- turn on headset
- start playing

hcidump output:
> HCI Event: Encrypt Change (0x08) plen 4
  00 0B 00 00 
> HCI Event: Role Change (0x12) plen 8
  00 E0 13 0F 7F 19 00 00 
> HCI Event: Encrypt Change (0x08) plen 4
  00 0B 00 01 
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
  0B 00 40 1F 00 00 40 1F 00 00 FF FF 60 00 FF 3F 00 
> HCI Event: Command Status (0x0f) plen 4
  00 01 28 04 
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
  00 01 00 E0 13 0F 7F 19 00 00 00 00 00 00 00 00 02 
> SCO data: handle 1 flags 0x00 dlen 48
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 
> SCO data: handle 1 flags 0x00 dlen 48
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 
...
Comment 1 Adam Szalkowski 2008-02-01 11:34:40 UTC
Created attachment 14677 [details]
Full hcidump
Comment 2 Adam Szalkowski 2008-02-01 11:42:19 UTC
Created attachment 14678 [details]
syslog output
Comment 3 Andrew Morton 2008-02-01 11:58:17 UTC
Marcel, this is a fairly recent regression.
Comment 4 Marcel Holtmann 2008-02-01 12:04:42 UTC
Having the "hcidump -X -V" would help a lot. Otherwise I have to decide the event content by hand which I not fancy at all.
Comment 5 Adam Szalkowski 2008-02-01 12:52:32 UTC
Created attachment 14679 [details]
New hcidump
Comment 6 Brian Rogers 2008-03-01 17:03:43 UTC
I have this problem and bisected it back to the following:

commit b6a0dc822497e1c0b9e8c4add270cc27fce48454
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Sat Oct 20 14:55:10 2007 +0200

    [Bluetooth] Add support for handling simple eSCO links

    With the Bluetooth 1.2 specification the Extended SCO feature for
    better audio connections was introduced. So far the Bluetooth core
    wasn't able to handle any eSCO connections correctly. This patch
    adds simple eSCO support while keeping backward compatibility with
    older devices.

    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Reverting this patch gets things working.
Comment 7 Marcel Holtmann 2008-03-05 01:47:51 UTC
My commit introduces a regression and we are currently figuring out how to fix it. We do have a full patch that restores full eSCO handling, but some have seen oopses with it. As an alternative we are going with a one-line fix that will default to SCO while leaving the full eSCO infrastructure in place.

Comment 8 Brian Rogers 2008-04-06 01:11:37 UTC
Actually, when I tried that patch with a vanilla kernel, I was never able to reproduce the oops. I only got that when I used the patch on the Ubuntu Hardy kernel. But there was another problem. With that patch applied, I would frequently (but not always) get loud static instead of the correct audio.

With eSCO completely disabled, I never get that static problem.
Comment 9 rajan batra 2009-03-15 07:53:21 UTC
Hi,
i seem to getting same issue:

>SCO Data: handle 45 flags 0x00 dlen 48.
>SCO Data: handle 45 flags 0x00 dlen 48.
>SCO Data: handle 45 flags 0x00 dlen 48.

i didn't really understand, what patch to apply !. i am using bluez 4.32.
kindly let me know.

thanks
Comment 10 rajan batra 2009-03-15 08:30:43 UTC
I now tried with 2.6.21 kernel and bluez 4.25. i get flood of >SCO messages
when i do headset.Play. i have attached the hcidump -X -V.
any pointers about which way should i go, or try new combination.
would be great as i am stuck.

if i call aplay or arecord.  i get error in bluetoothd. (this is irrespective
of whether i call headset.play or not)


Accepted new client connection on unix socket (fd=25)
Audio API: BT_REQUEST <- BT_GET_CAPABILITIES
Invalid message: length mismatch.

thanks.
Comment 11 rajan batra 2009-03-15 08:33:08 UTC
Created attachment 20530 [details]
hcidump -X -V against comment #10

Against comment #10
flood of SCO
Comment 12 Luis Diaz 2009-03-23 18:36:22 UTC
i get 45 and 46 handle error like:
" hci_scodata_packet: hci0 SCO packet for unknown connection handle 45 "

with disable_esco=1 i hear the headset beep, but then i get silence...

Ubuntu  2.6.27-11-generic
Comment 13 Brian J. Murrell 2009-12-31 14:47:09 UTC
I also experience this message:

[146784.785660] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.793077] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.800516] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.807918] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.815363] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.822767] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0
[146784.830172] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0

on Ubuntu's Karmic kernel 2.6.31-17-generic.

I also experience what seems to be a functioning headset with the exception that I don't hear anything in it except the beep when the audio stream stops.
Comment 14 Alan 2012-05-21 14:54:58 UTC
*** Bug 10270 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.