lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 28 Feb 2008 11:49:43 +0900
From:	Louis JANG <>
To:	Marcel Holtmann <>
CC:	Dave Young <>,,
	Linux Kernel <>,, David Miller <>,
	Netdev <>,
Subject: Re: [Bluez-devel] forcing SCO connection patch

Hi Marcel,

I changed what you said below and attached patch again.

And did you check Guillaume's patch for this issue? his patch try to
find again when ev->link_type is SCO_LINK only. I think his way is
better than mine. I haven't saw other case (LM is not support esco but
ESCO_LINK is connected) and I think it shouldn't happen in a normal

Best regards,
Louis JANG

Marcel Holtmann  :
> Hi Louis,
>> When bluez tried to connect SCO channel with
>> a real connection may be connected with SCO_LINK instead of ESCO_LINK
>> when
>> peer device doesn't support eSCO. however bluez try to find
>> connection handle
>> by event's link type(SCO_LINK in above case) and the valid connection
>> handle
>> for this event is waiting for ESCO_LINK. so bluez can't find
>> connection handle
>> and discarded the event.
> using HCI_OP_SETUP_SYNC_CONN doesn't mean eSCO. It is perfectly fine
> to request SCO links via that command. The difference here is
> Bluetooth 1.1 or 1.2 and later.
>> This patch is to handle different type of synchronous link is
>> estabilished
>> with its request.
>> If bluez can't find connection handle, it try to find with different
>> link type again. (For the above case, if bluez can't find connection
>> handle with SCO_LINK, it try to find connection handle with ESCO_LINK
>> again.)
>> and update link type of this connection handle with event's link type.
> Inside the kernel it is not called BlueZ :) It simply is the Bluetooth
> subsystem and in case the HCI core.
> Regards
> Marcel
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to
> More majordomo info at

View attachment "patch_hci_event.c7" of type "text/plain" (1529 bytes)

Powered by blists - more mailing lists