* Auto trust entry remove
From: Christian Birchinger @ 2010-05-24 8:33 UTC (permalink / raw)
To: linux-bluetooth
Hello
In another futile attempt to get a SixAxis controller working
i noticed that bluetoothd removes the trust entry that's needed
for that device to work.
It doesn't matter if i use some device management tool like blueman
or just add the entry directly before starting the daemon. The later
seems the less problematic way to make sure no external component
messes with the config.
I started bluetoothd in debug mode with -nd and it doesn't even and
it does this right after it does "HIDP: Control: Virtual cable unplug"
for a reason i don't know.
I only see in strace that it does this and after it the trusts
file is 0 bytes again:
open("/var/lib/bluetooth/... .../trusts", O_RDWR) = 23
I didn't get any input data before but at least i got it connect
and register it to the kernel as HID device before.
Is this auto-untrust by the bluetoothd itself something new?
This is a 2.6.34 kernel with bluez 4.64(+sixaxis cable patch).
It's a fresh installation but with known working hardware components.
The controller works and the USB dongle worked with it back in
the bluez 3.x days.
I'm thankfull for any hints. Below is a hcidump of the session
to the point where it self disconnects, resets trusts and then
gets a access denied because of it.
Bye, Christian
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x00e0
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e0 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e0 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e0 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e0 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x00e0 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e0 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x00e1
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e1 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e1 result 0 status 0
Connection successful
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e0 scid 0x0040
> ACL data: handle 11 flags 0x02 dlen 36
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 24
QoS 0x02 (Guaranteed)
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e1 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e1 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e1 scid 0x0041
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x00e1
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x00e1
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e1 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x00e2
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e2 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e2 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e2 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e2 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x00e2 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e2 scid 0x0040
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x00e3
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e3 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e3 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e2 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 36
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 24
QoS 0x02 (Guaranteed)
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e3 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e3 flags 0x00 clen 0
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e3 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e3 scid 0x0041
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x00e4
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e4 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e4 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e4 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e4 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x00e4 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e4 scid 0x0040
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x00e5
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e5 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e5 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e4 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 36
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 24
QoS 0x02 (Guaranteed)
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e5 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e5 flags 0x00 clen 0
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e5 scid 0x0041
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x00e5
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x00e5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e5 scid 0x0041
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x00e6
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e6 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e6 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e6 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e6 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x00e6 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e6 scid 0x0040
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x00e7
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e7 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e7 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e6 scid 0x0040
> ACL data: handle 11 flags 0x02 dlen 36
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 24
QoS 0x02 (Guaranteed)
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e7 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e7 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e7 scid 0x0041
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e7 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
< HCI Command: Disconnect (0x01|0x0006) plen 3
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Disconn Complete (0x05) plen 4
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Read Remote Supported Features (0x0b) plen 11
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
> HCI Event: Command Status (0x0f) plen 4
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x00e8
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e8 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x00e8 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x00e8 flags 0x00 result 0 clen 4
MTU 672
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x00e8 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x00e8 len 1 [psm 17]
HIDP: Control: Virtual cable unplug
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x00e8 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x00e9
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e9 result 1 status 2
Connection pending - Authorization pending
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e9 result 3 status 0
Connection refused - security block
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x00e8 scid 0x0040
^ permalink raw reply
* Re: Auto trust entry remove
From: Christian Birchinger @ 2010-05-24 8:53 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100524083330.GA18128@netswarm.net>
Ok, i copied over the "spd" and "profiles" entries from
the previous installation. Now it no longer removes the
trust after a reconnect. It's just stuck in a reconnect
loop (about 10 times) and then the controller gives up
and powers down.
^ permalink raw reply
* Re: Auto trust entry remove
From: Antonio Ospite @ 2010-05-24 9:31 UTC (permalink / raw)
To: Christian Birchinger; +Cc: linux-bluetooth
In-Reply-To: <20100524085344.GA18433@netswarm.net>
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On Mon, 24 May 2010 10:53:44 +0200
Christian Birchinger <joker@netswarm.net> wrote:
> Ok, i copied over the "spd" and "profiles" entries from
> the previous installation. Now it no longer removes the
> trust after a reconnect. It's just stuck in a reconnect
> loop (about 10 times) and then the controller gives up
> and powers down.
Christian, I can only say that it works for me with the kernel patches
from http://lists.ozlabs.org/pipermail/cbe-oss-dev/2010-May/007274.html
and an updated sixaxis-cable patch which I haven't published yet
because it was not final and I didn't want to leave temporary stuff,
which could be soon deprecated, archived on the Internet; that may
confuse people.
Let me know if you want me to send this updated sixaxis-cable to you
privately.
Have you tried removing everything from /var/lib/bluetooth ?
Regards,
Antonio.
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Auto trust entry remove
From: Christian Birchinger @ 2010-05-24 10:56 UTC (permalink / raw)
To: Antonio Ospite; +Cc: linux-bluetooth
In-Reply-To: <20100524113122.c084d160.ospite@studenti.unina.it>
On Mon, May 24, 2010 at 11:31:22AM +0200, Antonio Ospite wrote:
First of all i know what prevented the BT HID from being added.
The netlink plugin was disabled and that's required for this
to work. Really stupid mistake.
The device gets added now and for the first time i get input data
from it.
> On Mon, 24 May 2010 10:53:44 +0200
> Christian Birchinger <joker@netswarm.net> wrote:
>
> Christian, I can only say that it works for me with the kernel patches
> from http://lists.ozlabs.org/pipermail/cbe-oss-dev/2010-May/007274.html
> and an updated sixaxis-cable patch which I haven't published yet
> because it was not final and I didn't want to leave temporary stuff,
> which could be soon deprecated, archived on the Internet; that may
> confuse people.
Thanks for the hint, i just patched my kernel an rebooted. This is the
output when i plug the controller over USB:
sony 0003:054C:0268.0007: input,hiddev96,hidraw3: USB HID v1.11 Joystick [Sony PLAYSTATION(R)3 Controller] on usb-0000:00:1a.0-1.3.4/input0
sony 0003:054C:0268.0007: Calling sixaxis_set_operational_usb
sony 0003:054C:0268.0007: Sony PS3 Controller bdaddr: <controller addr>
So it works fine.
> Let me know if you want me to send this updated sixaxis-cable to you
> privately.
Yes, that would be interesting. Is there some default location to find
the recent public release of it too? I'm alsways exctracting it from
the Fedora srpm.
Thanks a lot for your help
Bye, Christian
^ permalink raw reply
* Re: Auto trust entry remove
From: Antonio Ospite @ 2010-05-24 11:10 UTC (permalink / raw)
To: Christian Birchinger; +Cc: linux-bluetooth
In-Reply-To: <20100524105659.GA19294@netswarm.net>
[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]
On Mon, 24 May 2010 12:56:59 +0200
Christian Birchinger <joker@netswarm.net> wrote:
> On Mon, May 24, 2010 at 11:31:22AM +0200, Antonio Ospite wrote:
>
> First of all i know what prevented the BT HID from being added.
> The netlink plugin was disabled and that's required for this
> to work. Really stupid mistake.
>
> The device gets added now and for the first time i get input data
> from it.
>
Good.
> > On Mon, 24 May 2010 10:53:44 +0200
> > Christian Birchinger <joker@netswarm.net> wrote:
> >
> > Christian, I can only say that it works for me with the kernel patches
> > from http://lists.ozlabs.org/pipermail/cbe-oss-dev/2010-May/007274.html
> > and an updated sixaxis-cable patch which I haven't published yet
> > because it was not final and I didn't want to leave temporary stuff,
> > which could be soon deprecated, archived on the Internet; that may
> > confuse people.
>
> Thanks for the hint, i just patched my kernel an rebooted. This is the
> output when i plug the controller over USB:
>
> sony 0003:054C:0268.0007: input,hiddev96,hidraw3: USB HID v1.11 Joystick [Sony PLAYSTATION(R)3 Controller] on usb-0000:00:1a.0-1.3.4/input0
> sony 0003:054C:0268.0007: Calling sixaxis_set_operational_usb
> sony 0003:054C:0268.0007: Sony PS3 Controller bdaddr: <controller addr>
>
> So it works fine.
>
Yes.
> > Let me know if you want me to send this updated sixaxis-cable to you
> > privately.
>
> Yes, that would be interesting. Is there some default location to find
> the recent public release of it too? I'm alsways exctracting it from
> the Fedora srpm.
>
The one from Fedora srpm uses libusb and hence has to detach and
reattach the usbhid driver in order to work. With my patch+my
sixaxis-cable plugin libusb is not needed anymore, but I am not
publishing it because I didn't receive feedback on those kernel patches
from kernel people, and I feel that means extending hidraw should be the
way, I just haven't found the time to work on it yet. I am sending the
sixaxis-cable plugin to you in another mail just to show the concept,
don't distribute it yet, keep in mind that it should be changed to use
hidraw once I finished with this.
> Thanks a lot for your help
> Bye, Christian
>
You're welcome.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCHv2 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn
From: Andrei Emeltchenko @ 2010-05-24 12:14 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100523023906.GB3385@vigoh>
Hi Gustavo
On Sun, May 23, 2010 at 5:39 AM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-05-21 13:04:52 +0300]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Check that socket sk is not locked in user process before removing
>> l2cap connection handler.
>>
>> krfcommd kernel thread may be preempted with l2cap tasklet which remove
>> l2cap_conn structure. If krfcommd is in process of sending of RFCOMM reply
>> (like "RFCOMM UA" reply to "RFCOMM DISC") then kernel crash happens.
>>
>> ...
>> [ 694.175933] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> [ 694.184936] pgd = c0004000
>> [ 694.187683] [00000000] *pgd=00000000
>> [ 694.191711] Internal error: Oops: 5 [#1] PREEMPT
>> [ 694.196350] last sysfs file: /sys/devices/platform/hci_h4p/firmware/hci_h4p/loading
>> [ 694.260375] CPU: 0 Not tainted (2.6.32.10 #1)
>> [ 694.265106] PC is at l2cap_sock_sendmsg+0x43c/0x73c [l2cap]
>> [ 694.270721] LR is at 0xd7017303
>> ...
>> [ 694.525085] Backtrace:
>> [ 694.527587] [<bf266be0>] (l2cap_sock_sendmsg+0x0/0x73c [l2cap]) from [<c02f2cc8>] (sock_sendmsg+0xb8/0xd8)
>> [ 694.537292] [<c02f2c10>] (sock_sendmsg+0x0/0xd8) from [<c02f3044>] (kernel_sendmsg+0x48/0x80)
>> ...
>>
>> Modified version after comments of Gustavo F. Padovan <gustavo@padovan.org>
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap.c | 25 +++++++++++++++++++++++++
>> 1 files changed, 25 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index bb00015..11060d6 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -2927,6 +2927,13 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
>> break;
>>
>> default:
>> + /* don't delete l2cap channel if sk is owned by user */
>> + if (sock_owned_by_user(sk)) {
>> + sk->sk_state = BT_DISCONN;
>> + l2cap_sock_clear_timer(sk);
>> + l2cap_sock_set_timer(sk, HZ);
>
> Using the sock timer like you are you using looks too hackish, there are
> kernel struct for such defer works. I still prefer the first solution,
> that avoids the call to l2cap_chan_del() only.
OK. Then let's go for the first solution.
> But we have to solve the problem with the sock_kill() call, I'm
> wondering if add a check inside l2cap_sock_kill is good idea. So we
> check if the socket is owned by user and if yes, we just return, however
> may have problem with socket refcnt doing that.
I think by just using refcounting (sock_hold / sock_put) we overcome
the problem.
No need for extra checks; they looks hackish when we can use proper way.
> Looking to the rfcomm code I found something that could be cause of the
> problem, there isn't any sock_hold() in the rfcomm code, maybe is it
> missing? Nevertheless it does the sock_put() without call sock_hold().
Do you mean it is unbalanced? sock_hold is probably executed in some
function returning sk (which is not the best practice).
> Like you I'm trying to figure out how to fix this issue, I don't know
> yet how to fix it properly. I advice to take a look on the rfcomm code
> and check if we really are missing a sock_hold() there.
My first version of the patch adds refcounting to RFCOMM send function.
> Also is not easy to reproduce such sequence of l2cap and rfcomm packets,
> so I can't test the issue here too.
I guess this is harder to reproduce with desktop system but you can
add mdelay when sending RFCOMM. This way tasklet has more chances to
preempt krfcommd process.
@@ -1668,6 +1671,8 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct
if (err)
goto done;
+ mdelay(100);
+
if (msg->msg_flags & MSG_OOB) {
err = -EOPNOTSUPP;
goto done;
Could you try adding mdelay? There are reports that reproducing is
possible with rctest
Regards,
Andrei
^ permalink raw reply
* [PATCH 0/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-05-24 21:10 UTC (permalink / raw)
To: linux-bluetooth
Marcel:
This patch resolves some issues with what looks to be certain CSR
based headsets. When requesting SCO or eSCO while the connection
is transitioning from sniff to active, i.e. unsniff has been requested
but the headset has not responded with accepted, these headsets seem
to enter a state where they don't positively respond the SCO/eSCO
request. This was first noticed in and Motorola H350 Headset.
In addition, I've cleaned up some extraneous spaces and the original
Copyright has been changed from Qualcomm to Code Aurora Forum as
Qualcomm has reassigned these rights to Code Aurora Forum.
--
Ron Shaffer
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-05-24 21:11 UTC (permalink / raw)
To: linux-bluetooth
Certain headsets such as the Motorola H350 will reject SCO and eSCO
connection requests while the ACL is transitioning from sniff mode
to active mode. Add synchronization so that SCO and eSCO connection
requests will wait until the ACL has fully transitioned to active mode.
Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
---
include/net/bluetooth/hci_core.h | 17 +++++++++--------
net/bluetooth/hci_conn.c | 20 +++++++++++++++++++-
net/bluetooth/hci_event.c | 26 ++++++++++++++++++++++++--
3 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e42f6ed..c4a37fc 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1,6 +1,6 @@
-/*
+/*
BlueZ - Bluetooth protocol stack for Linux
- Copyright (C) 2000-2001 Qualcomm Incorporated
+ Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
@@ -12,13 +12,13 @@
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
- CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
- WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
+ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
- COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
+ ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
+ COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
SOFTWARE IS DISCLAIMED.
*/
@@ -250,6 +250,7 @@ enum {
HCI_CONN_ENCRYPT_PEND,
HCI_CONN_RSWITCH_PEND,
HCI_CONN_MODE_CHANGE_PEND,
+ HCI_CONN_SCO_PEND,
};
static inline void hci_conn_hash_init(struct hci_dev *hdev)
@@ -380,7 +381,7 @@ static inline void __hci_dev_put(struct hci_dev *d)
}
static inline void hci_dev_put(struct hci_dev *d)
-{
+{
__hci_dev_put(d);
module_put(d->owner);
}
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b10e3cd..5c4e3c1 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1,6 +1,6 @@
/*
BlueZ - Bluetooth protocol stack for Linux
- Copyright (C) 2000-2001 Qualcomm Incorporated
+ Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
@@ -117,9 +117,18 @@ void hci_add_sco(struct hci_conn *conn, __u16 handle)
{
struct hci_dev *hdev = conn->hdev;
struct hci_cp_add_sco cp;
+ struct hci_conn *acl = conn->link;
BT_DBG("%p", conn);
+ if (acl->mode == HCI_CM_SNIFF &&
+ test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
+ set_bit(HCI_CONN_SCO_PEND, &conn->pend);
+ return;
+ }
+
+ clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
+
conn->state = BT_CONNECT;
conn->out = 1;
@@ -135,9 +144,18 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
{
struct hci_dev *hdev = conn->hdev;
struct hci_cp_setup_sync_conn cp;
+ struct hci_conn *acl = conn->link;
BT_DBG("%p", conn);
+ if (acl->mode == HCI_CM_SNIFF &&
+ test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
+ set_bit(HCI_CONN_SCO_PEND, &conn->pend);
+ return;
+ }
+
+ clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
+
conn->state = BT_CONNECT;
conn->out = 1;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6c57fc7..22fb095 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1,6 +1,6 @@
/*
BlueZ - Bluetooth protocol stack for Linux
- Copyright (C) 2000-2001 Qualcomm Incorporated
+ Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
@@ -615,6 +615,7 @@ static void hci_cs_add_sco(struct hci_dev *hdev, __u8 status)
acl = hci_conn_hash_lookup_handle(hdev, handle);
if (acl && (sco = acl->link)) {
sco->state = BT_CLOSED;
+ clear_bit(HCI_CONN_SCO_PEND, &sco->pend);
hci_proto_connect_cfm(sco, status);
hci_conn_del(sco);
@@ -760,6 +761,7 @@ static void hci_cs_setup_sync_conn(struct hci_dev *hdev, __u8 status)
acl = hci_conn_hash_lookup_handle(hdev, handle);
if (acl && (sco = acl->link)) {
sco->state = BT_CLOSED;
+ clear_bit(HCI_CONN_SCO_PEND, &sco->pend);
hci_proto_connect_cfm(sco, status);
hci_conn_del(sco);
@@ -795,6 +797,7 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
{
struct hci_cp_exit_sniff_mode *cp;
struct hci_conn *conn;
+ struct hci_conn *sco;
BT_DBG("%s status 0x%x", hdev->name, status);
@@ -808,9 +811,18 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
+ if (conn) {
clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ sco = conn->link;
+ if (sco) {
+ if (test_and_clear_bit(HCI_CONN_SCO_PEND, &sco->pend)) {
+ hci_proto_connect_cfm(sco, status);
+ hci_conn_del(sco);
+ }
+ }
+ }
+
hci_dev_unlock(hdev);
}
@@ -1463,6 +1475,7 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
{
struct hci_ev_mode_change *ev = (void *) skb->data;
struct hci_conn *conn;
+ struct hci_conn *sco;
BT_DBG("%s status %d", hdev->name, ev->status);
@@ -1478,6 +1491,15 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
conn->power_save = 1;
else
conn->power_save = 0;
+ } else {
+ sco = conn->link;
+ if (sco && test_and_clear_bit(HCI_CONN_SCO_PEND,
+ &sco->pend)) {
+ if (lmp_esco_capable(hdev))
+ hci_setup_sync(sco, conn->handle);
+ else
+ hci_add_sco(sco, conn->handle);
+ }
}
}
--
1.7.0.2
--
Ron Shaffer
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: [PATCH 0/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Gustavo F. Padovan @ 2010-05-24 21:19 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4BFAEB5C.4040300@codeaurora.org>
Hi Ron,
* Ron Shaffer <rshaffer@codeaurora.org> [2010-05-24 16:10:52 -0500]:
> Marcel:
>
> This patch resolves some issues with what looks to be certain CSR
> based headsets. When requesting SCO or eSCO while the connection
> is transitioning from sniff to active, i.e. unsniff has been requested
> but the headset has not responded with accepted, these headsets seem
> to enter a state where they don't positively respond the SCO/eSCO
> request. This was first noticed in and Motorola H350 Headset.
>
> In addition, I've cleaned up some extraneous spaces and the original
> Copyright has been changed from Qualcomm to Code Aurora Forum as
> Qualcomm has reassigned these rights to Code Aurora Forum.
Could you please split this patch in 3 patches? Clearly it mixes 3 things:
your fix, the copyright change, and the cleanup.
>
> --
> Ron Shaffer
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Gustavo F. Padovan @ 2010-05-24 21:52 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4BFAEB65.2060503@codeaurora.org>
Hi Ron,
* Ron Shaffer <rshaffer@codeaurora.org> [2010-05-24 16:11:01 -0500]:
>
> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> connection requests while the ACL is transitioning from sniff mode
> to active mode. Add synchronization so that SCO and eSCO connection
> requests will wait until the ACL has fully transitioned to active mode.
>
> Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
> ---
> include/net/bluetooth/hci_core.h | 17 +++++++++--------
> net/bluetooth/hci_conn.c | 20 +++++++++++++++++++-
> net/bluetooth/hci_event.c | 26 ++++++++++++++++++++++++--
> 3 files changed, 52 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index e42f6ed..c4a37fc 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -1,6 +1,6 @@
> -/*
> +/*
> BlueZ - Bluetooth protocol stack for Linux
> - Copyright (C) 2000-2001 Qualcomm Incorporated
> + Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
>
> Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
>
> @@ -12,13 +12,13 @@
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
> IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
> - CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
> - WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> - ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
> + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>
> - ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
> - COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> + ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
> + COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
> SOFTWARE IS DISCLAIMED.
> */
>
> @@ -250,6 +250,7 @@ enum {
> HCI_CONN_ENCRYPT_PEND,
> HCI_CONN_RSWITCH_PEND,
> HCI_CONN_MODE_CHANGE_PEND,
> + HCI_CONN_SCO_PEND,
> };
>
> static inline void hci_conn_hash_init(struct hci_dev *hdev)
> @@ -380,7 +381,7 @@ static inline void __hci_dev_put(struct hci_dev *d)
> }
>
> static inline void hci_dev_put(struct hci_dev *d)
> -{
> +{
> __hci_dev_put(d);
> module_put(d->owner);
> }
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index b10e3cd..5c4e3c1 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -1,6 +1,6 @@
> /*
> BlueZ - Bluetooth protocol stack for Linux
> - Copyright (C) 2000-2001 Qualcomm Incorporated
> + Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
>
> Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
>
> @@ -117,9 +117,18 @@ void hci_add_sco(struct hci_conn *conn, __u16 handle)
> {
> struct hci_dev *hdev = conn->hdev;
> struct hci_cp_add_sco cp;
> + struct hci_conn *acl = conn->link;
>
> BT_DBG("%p", conn);
>
> + if (acl->mode == HCI_CM_SNIFF &&
> + test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
Wrong indentation here. Add a extra tab for test_bit.
> + set_bit(HCI_CONN_SCO_PEND, &conn->pend);
> + return;
> + }
> +
> + clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
You already clear the bit on hci_mode_change_evt with
test_and_clear_bit. No need to clear it again here.
The same happens for hci_setup_sync().
> +
> conn->state = BT_CONNECT;
> conn->out = 1;
>
> @@ -135,9 +144,18 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
> {
> struct hci_dev *hdev = conn->hdev;
> struct hci_cp_setup_sync_conn cp;
> + struct hci_conn *acl = conn->link;
>
> BT_DBG("%p", conn);
>
> + if (acl->mode == HCI_CM_SNIFF &&
> + test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
Wrong indentation here too.
> + set_bit(HCI_CONN_SCO_PEND, &conn->pend);
> + return;
> + }
> +
> + clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
> +
> conn->state = BT_CONNECT;
> conn->out = 1;
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 6c57fc7..22fb095 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1,6 +1,6 @@
> /*
> BlueZ - Bluetooth protocol stack for Linux
> - Copyright (C) 2000-2001 Qualcomm Incorporated
> + Copyright (c) 2000-2001, 2010, Code Aurora Forum. All rights reserved.
>
> Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
>
> @@ -615,6 +615,7 @@ static void hci_cs_add_sco(struct hci_dev *hdev, __u8 status)
> acl = hci_conn_hash_lookup_handle(hdev, handle);
> if (acl && (sco = acl->link)) {
> sco->state = BT_CLOSED;
> + clear_bit(HCI_CONN_SCO_PEND, &sco->pend);
>
> hci_proto_connect_cfm(sco, status);
> hci_conn_del(sco);
> @@ -760,6 +761,7 @@ static void hci_cs_setup_sync_conn(struct hci_dev *hdev, __u8 status)
> acl = hci_conn_hash_lookup_handle(hdev, handle);
> if (acl && (sco = acl->link)) {
> sco->state = BT_CLOSED;
> + clear_bit(HCI_CONN_SCO_PEND, &sco->pend);
>
> hci_proto_connect_cfm(sco, status);
> hci_conn_del(sco);
> @@ -795,6 +797,7 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
> {
> struct hci_cp_exit_sniff_mode *cp;
> struct hci_conn *conn;
> + struct hci_conn *sco;
>
> BT_DBG("%s status 0x%x", hdev->name, status);
>
> @@ -808,9 +811,18 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> - if (conn)
> + if (conn) {
> clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>
> + sco = conn->link;
> + if (sco) {
> + if (test_and_clear_bit(HCI_CONN_SCO_PEND, &sco->pend)) {
Wouldn't be better 'if (sco && test_and_clear_bit(...' ?
> + hci_proto_connect_cfm(sco, status);
> + hci_conn_del(sco);
> + }
> + }
> + }
> +
> hci_dev_unlock(hdev);
> }
>
> @@ -1463,6 +1475,7 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
> {
> struct hci_ev_mode_change *ev = (void *) skb->data;
> struct hci_conn *conn;
> + struct hci_conn *sco;
>
> BT_DBG("%s status %d", hdev->name, ev->status);
>
> @@ -1478,6 +1491,15 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
> conn->power_save = 1;
> else
> conn->power_save = 0;
> + } else {
> + sco = conn->link;
> + if (sco && test_and_clear_bit(HCI_CONN_SCO_PEND,
> + &sco->pend)) {
> + if (lmp_esco_capable(hdev))
> + hci_setup_sync(sco, conn->handle);
> + else
> + hci_add_sco(sco, conn->handle);
> + }
> }
> }
>
> --
> 1.7.0.2
>
> --
> Ron Shaffer
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: WRT non-UTF-8 device names
From: Fabian Greffrath @ 2010-05-25 11:35 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1274432516.4068.29.camel@vfrodo>
Dear Bluez developers,
Am 21.05.2010 11:01, schrieb Fabian Greffrath:
> Long story short: If the bluetooth adapter's device name contains
> non-UTF-8 characters (which my dongle does by default), it requires a
> manual device name change and a restart of the daemon (!) to bring the
> device back to life. I have previously posted a patch to this list which
> fixes this issue by instantly converting faulty device names to UTF-8
> and writing them back to the device during the device configuration
> phase:
>
> <http://marc.info/?l=linux-bluetooth&m=127315737929319&w=2>
>
> However, I have been told that my "patch might be just working around
> the real issue instead of fixing it" and that "It sounds like there's
> something else wrong in the initialization process which makes the
> initialzation fail if the adapter contains some invalid default name".
>
> So, please, try the steps I presented above yourself and tell me what is
> wrong so I can attempt to fix the root of the problem. I am really
> itching to get this issue fixed in the short term.
this is a real issue (it bites me each and every time I plug in my USB
Bluetooth dongle) and it is easily reproducible following the simple
steps I have posted earlier. Please give me a hint how to track down
this bug and fix it.
Thanks,
Fabian
^ permalink raw reply
* Re: WRT non-UTF-8 device names
From: Bastien Nocera @ 2010-05-25 12:38 UTC (permalink / raw)
To: Fabian Greffrath; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1274432516.4068.29.camel@vfrodo>
On Fri, 2010-05-21 at 11:01 +0200, Fabian Greffrath wrote:
> Dear Bluez list,
>
> I am experiencing the following issues with the bluez 4.63-2 and
> gnome-bluetooth 2.30.0-1 packages from Debian unstable:
Stupid question, but do you use a UTF-8 locale, or not?
The output of "locale" as root would probably help.
My guess is that we make assumptions as to a user entry being valid
UTF-8 somewhere, when it could be non-UTF-8.
As for your problem, I don't think we want to allow non-UTF-8 device
names anyhow. They're not valid spec.
^ permalink raw reply
* Re: WRT non-UTF-8 device names
From: Fabian Greffrath @ 2010-05-25 12:56 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1274791119.27274.17718.camel@localhost.localdomain>
Am 25.05.2010 14:38, schrieb Bastien Nocera:
> The output of "locale" as root would probably help.
Here you are:
$ su -c locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
> My guess is that we make assumptions as to a user entry being valid
> UTF-8 somewhere, when it could be non-UTF-8.
>
> As for your problem, I don't think we want to allow non-UTF-8 device
> names anyhow. They're not valid spec.
Sure, that's why my patch converts the device name to valid UTF-8 as
soon as it is possible to detect that it is actually non-UTF-8.
However, it may be right that this approach only fixes the symptoms
and does not cure the illness. But my knowledge of the Bluez code is
not deep enough to track down the real issue on my own.
Thanks for your reply anyway,
Fabian
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-05-25 17:00 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100524215202.GA28028@vigoh>
trimmed.
> Hi Ron,
>
> * Ron Shaffer <rshaffer@codeaurora.org> [2010-05-24 16:11:01 -0500]:
>
>>
>> Certain headsets such as the Motorola H350 will reject SCO and eSCO
>> connection requests while the ACL is transitioning from sniff mode
>> to active mode. Add synchronization so that SCO and eSCO connection
>> requests will wait until the ACL has fully transitioned to active mode.
>>
>> Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
> @@ -117,9 +117,18 @@ void hci_add_sco(struct hci_conn *conn, __u16 handle)
> > {
> > struct hci_dev *hdev = conn->hdev;
> > struct hci_cp_add_sco cp;
> > + struct hci_conn *acl = conn->link;
> >
> > BT_DBG("%p", conn);
> >
> > + if (acl->mode == HCI_CM_SNIFF &&
> > + test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
> Wrong indentation here. Add a extra tab for test_bit.
> > + set_bit(HCI_CONN_SCO_PEND, &conn->pend);
> > + return;
> > + }
> > +
> > + clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
>
>
> You already clear the bit on hci_mode_change_evt with
> test_and_clear_bit. No need to clear it again here.
> The same happens for hci_setup_sync().
>
Clearing the bit and clearing it in hci_change_mode_evt are independent
actions for two different scenarios.
Scenario 1:
A SCO/eSCO connection is requested and the ACL is in active mode.
Scenario 2:
A SCO/eSCO connection is requested and the ACL is transitioning modes.
For scenario 1, I cleared the bit here because I did not want to assume
the bit had been initialized. If it's set, then any future changes to
the ACL mode (sniff, active) requested by the local side would result
in a request for a SCO or eSCO connection when one already exists.
For scenario 2, the first conditional is TRUE, and the bit gets set.
Later when the mode change event is received, the bit is cleared and
the SCO/eSCO connection is requested.
--
Ron Shaffer
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Gustavo F. Padovan @ 2010-05-25 20:09 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4BFC0228.8050206@codeaurora.org>
Hi Ron,
* Ron Shaffer <rshaffer@codeaurora.org> [2010-05-25 12:00:24 -0500]:
> trimmed.
>
> > Hi Ron,
> >
> > * Ron Shaffer <rshaffer@codeaurora.org> [2010-05-24 16:11:01 -0500]:
> >
> >>
> >> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> >> connection requests while the ACL is transitioning from sniff mode
> >> to active mode. Add synchronization so that SCO and eSCO connection
> >> requests will wait until the ACL has fully transitioned to active mode.
> >>
> >> Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
>
> > @@ -117,9 +117,18 @@ void hci_add_sco(struct hci_conn *conn, __u16 handle)
> > > {
> > > struct hci_dev *hdev = conn->hdev;
> > > struct hci_cp_add_sco cp;
> > > + struct hci_conn *acl = conn->link;
> > >
> > > BT_DBG("%p", conn);
> > >
> > > + if (acl->mode == HCI_CM_SNIFF &&
> > > + test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
> > Wrong indentation here. Add a extra tab for test_bit.
>
> > > + set_bit(HCI_CONN_SCO_PEND, &conn->pend);
> > > + return;
> > > + }
> > > +
> > > + clear_bit(HCI_CONN_SCO_PEND, &conn->pend);
>
> >
> >
> > You already clear the bit on hci_mode_change_evt with
> > test_and_clear_bit. No need to clear it again here.
> > The same happens for hci_setup_sync().
> >
>
> Clearing the bit and clearing it in hci_change_mode_evt are independent
> actions for two different scenarios.
>
> Scenario 1:
> A SCO/eSCO connection is requested and the ACL is in active mode.
>
> Scenario 2:
> A SCO/eSCO connection is requested and the ACL is transitioning modes.
>
> For scenario 1, I cleared the bit here because I did not want to assume
> the bit had been initialized. If it's set, then any future changes to
> the ACL mode (sniff, active) requested by the local side would result
> in a request for a SCO or eSCO connection when one already exists.
>
> For scenario 2, the first conditional is TRUE, and the bit gets set.
> Later when the mode change event is received, the bit is cleared and
> the SCO/eSCO connection is requested.
Acked.
>
> --
> Ron Shaffer
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Software caused connection abort (103 )
From: john michelle @ 2010-05-26 3:23 UTC (permalink / raw)
To: Gustavo F. Padovan, linux-bluetooth
In-Reply-To: <AANLkTinnJqmC6pB9pCTPy_YgGsgataba8nun9bsuufJF@mail.gmail.com>
Hi Gustavo,
> I tried reproduce this issue in L2CAP but it is a bit hard, lets
> say it happen once in a thousand, so it's not easy to track it. I have
> to try reproduce that using the SCO, but I'm not used to that layer yet.
> ;)
I think the Bluetooth dongle that i am using might be causing the
problem since it Automatically disconnects which lead to software
caused connection abort problem
Beside i found a new problem and that is from time to time the dongle
shifts the audio
Stream which makes it appear as static noise i tried to contact the
vendor of the dongle
Trust.com regarding the noise problem they told me " We regret to
inform you that Trust Doesn't provide any support for Linux for the
moment." so i guess in order to debug this
Problem properly i have to change the Bluetooth dongle so what type of
Bluetooth Dongle do you recommend that has linux support.
john
On Mon, May 17, 2010 at 5:32 PM, john michelle <jhnmichelle@gmail.com> wrote:
> One more Addition
>
>>> The problem happens when you are already tranfering
>>> SCO data?
>
> yes, it happens only during transferring SCO data
>
> john
>
>
> On Mon, May 17, 2010 at 5:21 PM, john michelle <jhnmichelle@gmail.com> wrote:
>>> Hi Jonh,
>>>
>>> First of all, don't do top posting in this mailing list. ;)
>>>
>>
>> Thanks for the advise , will keep that in mind for future posts.
>>
>>> In which bluez/kernel version the problem started? Any hardware update
>>> during this time? The problem happens when you are already tranfering
>>> SCO data?
>>>
>>
>> I tried bluez versions 3.XX and kernel 2.6.26(I think) the problem
>> occurs and the kernel panics with no core dumps.then i tried with
>> bluez 4.53-4.62 with
>> Kernel 2.6.31 and 2.6.32. the connection abort problem occurs but the
>> kernel doesn't
>> Panic. regarding the hardware update you mean the dongle or the box.Anyway
>> i changed both and tried different box's, this even happens on a box
>> with 2 giga ram
>> And core2 processor . as for the dongles i am using trust
>>
>> http://www.twenga.co.uk/prices-Bluetooth-2-USB-Adapter-10m-BT-2250p-TRUST-Wireless-network-card-adapter-176178-0
>>
>> and also using no name dongles all the same problem.
>>
>>> Please post the output of hcidump when the connection abort happens.
>>>
>>
>> well that is going to be a hard one since i have more than one dongle in place
>> And very hard to predict which one will crash.i will work on this and update
>> You as soon as i have the hcidump log.
>>
>>
>>
>>> I tried reproduce this issue in L2CAP but it is a bit hard, lets
>>> say it happen once in a thousand, so it's not easy to track it. I have
>>> to try reproduce that using the SCO, but I'm not used to that layer yet.
>>> ;)
>>
>> I hoped that it happens 1 in 1000 in SCO , but it actually happens 1 in 15
>>
>>
>> John
>>
>>
>>
>>>
>>> Regards,
>>>
>>>>
>>>> John
>>>>
>>>> On Fri, May 7, 2010 at 3:53 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>>>> > * john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05 -0400]:
>>>> >
>>>> >> Hi Bluetooth hackers,
>>>> >>
>>>> >> i am having this consistent problem with bluez , from time to time i
>>>> >> get the error Software caused connection abort (103 )
>>>> >> And the bluetooth stick seems to disconnect and reconnects. this
>>>> >> happens during an sco connection and it occurs even
>>>> >> More when i am having the voice stream comming through the internet
>>>> >> rather than the lan.i don't know what exact
>>>> >> Details you need to solve this problem please tell me and i will give
>>>> >> you an immediate reply . i have linux kernel 2.6.33 and bluez 4.62
>>>> >
>>>> > I get the same problem sometimes when testing ERTM with l2test. So the
>>>> > problem is on l2cap too. I didn't have time to debug this yet. Now that
>>>> > someone else have confirmed it too, I'll to take a look at the problem.
>>>> >
>>>> >>
>>>
>>> --
>>> Gustavo F. Padovan
>>> http://padovan.org
>>>
>>
>
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Marcel Holtmann @ 2010-05-26 8:59 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4BFAEB65.2060503@codeaurora.org>
Hi Ron,
> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> connection requests while the ACL is transitioning from sniff mode
> to active mode. Add synchronization so that SCO and eSCO connection
> requests will wait until the ACL has fully transitioned to active mode.
I am not completely happy with this patch. First please split it like
Gustavo asked since otherwise it becomes pretty hard to review. I don't
really bother to look into its technical nature before the split and the
coding style is in place.
Second, please don't make a special case for sniff mode. If we do this
then we also do it for park state and hold mode.
And third, I think this needs to be done a little bit more in the way we
handle attempts for connecting ACL links when the baseband is busy. So
can you send hcidump -X -V traces for the failure of SCO/eSCO setup when
sniff is active. I like to see which error codes are returned. Hacking
this directly into sniff exit handling makes the code pretty hard to
understand in the future.
Regards
Marcel
^ permalink raw reply
* [PATCHv1 0/2] Don't delete l2cap chan and sk when sk is owned by user
From: Emeltchenko Andrei @ 2010-05-26 14:21 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
When sk is owned by user we shall not delete l2cap shannel structures and socket sk.
The first patch which is less hackish than using timer to delete l2cap channel.
Andrei Emeltchenko (2):
Bluetooth: Check sk is not owned before freeing l2cap_conn
Bluetooth: Prevent sk freeing in tasklet using refcount
net/bluetooth/l2cap.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCHv1 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn
From: Emeltchenko Andrei @ 2010-05-26 14:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1274883694-18120-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Check that socket sk is not locked in user process before removing
l2cap connection handler.
krfcommd kernel thread may be preempted with l2cap tasklet which remove
l2cap_conn structure. If krfcommd is in process of sending of RFCOMM reply
(like "RFCOMM UA" reply to "RFCOMM DISC") then kernel crash happens.
...
[ 694.175933] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 694.184936] pgd = c0004000
[ 694.187683] [00000000] *pgd=00000000
[ 694.191711] Internal error: Oops: 5 [#1] PREEMPT
[ 694.196350] last sysfs file: /sys/devices/platform/hci_h4p/firmware/hci_h4p/loading
[ 694.260375] CPU: 0 Not tainted (2.6.32.10 #1)
[ 694.265106] PC is at l2cap_sock_sendmsg+0x43c/0x73c [l2cap]
[ 694.270721] LR is at 0xd7017303
...
[ 694.525085] Backtrace:
[ 694.527587] [<bf266be0>] (l2cap_sock_sendmsg+0x0/0x73c [l2cap]) from [<c02f2cc8>] (sock_sendmsg+0xb8/0xd8)
[ 694.537292] [<c02f2c10>] (sock_sendmsg+0x0/0xd8) from [<c02f3044>] (kernel_sendmsg+0x48/0x80)
...
Modified version after comments of Gustavo F. Padovan <gustavo@padovan.org>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index bb00015..794f2b7 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2927,7 +2927,9 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
break;
default:
- l2cap_chan_del(sk, ECONNREFUSED);
+ /* delete l2cap channel if sk is not owned by user */
+ if (!sock_owned_by_user(sk))
+ l2cap_chan_del(sk, ECONNREFUSED);
break;
}
@@ -3135,7 +3137,10 @@ static inline int l2cap_disconnect_req(struct l2cap_conn *conn, struct l2cap_cmd
del_timer(&l2cap_pi(sk)->ack_timer);
}
- l2cap_chan_del(sk, ECONNRESET);
+ /* delete l2cap channel if sk is not owned by user */
+ if (!sock_owned_by_user(sk))
+ l2cap_chan_del(sk, ECONNRESET);
+
bh_unlock_sock(sk);
l2cap_sock_kill(sk);
@@ -3167,7 +3172,10 @@ static inline int l2cap_disconnect_rsp(struct l2cap_conn *conn, struct l2cap_cmd
del_timer(&l2cap_pi(sk)->ack_timer);
}
- l2cap_chan_del(sk, 0);
+ /* delete l2cap channel if sk is not owned by user */
+ if (!sock_owned_by_user(sk))
+ l2cap_chan_del(sk, 0);
+
bh_unlock_sock(sk);
l2cap_sock_kill(sk);
--
1.7.0.4
^ permalink raw reply related
* [PATCHv1 2/2] Bluetooth: Prevent sk freeing in tasklet using refcount
From: Emeltchenko Andrei @ 2010-05-26 14:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1274883694-18120-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Socket sk may be freed in tasklet while still be in use in krfcommd
process. Use refcount to mark sk as used.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 794f2b7..bf762d6 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1724,6 +1724,7 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
+ sock_hold(sk);
lock_sock(sk);
if (sk->sk_state != BT_CONNECTED) {
@@ -1808,6 +1809,7 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
done:
release_sock(sk);
+ sock_put(sk);
return err;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-05-26 14:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1274864356.27220.155.camel@localhost.localdomain>
Marcel:
> Hi Ron,
>
>> Certain headsets such as the Motorola H350 will reject SCO and eSCO
>> connection requests while the ACL is transitioning from sniff mode
>> to active mode. Add synchronization so that SCO and eSCO connection
>> requests will wait until the ACL has fully transitioned to active mode.
>
> I am not completely happy with this patch. First please split it like
> Gustavo asked since otherwise it becomes pretty hard to review. I don't
> really bother to look into its technical nature before the split and the
> coding style is in place.
>
> Second, please don't make a special case for sniff mode. If we do this
> then we also do it for park state and hold mode.
>
> And third, I think this needs to be done a little bit more in the way we
> handle attempts for connecting ACL links when the baseband is busy. So
> can you send hcidump -X -V traces for the failure of SCO/eSCO setup when
> sniff is active. I like to see which error codes are returned. Hacking
> this directly into sniff exit handling makes the code pretty hard to
> understand in the future.
>
> Regards
>
> Marcel
>
>
Thanks for the review and comments.
I'll split the patch into three. No problem. When I resubmit, I'll push
the hcidump log out as well. Because the failure occurs during eSCO
negotiation and SCO request with the remote, most of the interesting
stuff is in LMP, so I'll include the FTS sniffer trace as well.
--
Ron Shaffer
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Marcel Holtmann @ 2010-05-26 15:31 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4BFD307B.6060805@codeaurora.org>
Hi Ron,
> I'll split the patch into three. No problem. When I resubmit, I'll push
> the hcidump log out as well. Because the failure occurs during eSCO
> negotiation and SCO request with the remote, most of the interesting
> stuff is in LMP, so I'll include the FTS sniffer trace as well.
don't bother with FTS traces. I don't care. I just need to see the
output of hcidump -X -V so that I can figure out what the problem is
here and what are possible solutions. Send the hcidump now before
redoing the patches.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-05-26 21:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1274887917.27220.166.camel@localhost.localdomain>
Marcel,
> Hi Ron,
>
>> I'll split the patch into three. No problem. When I resubmit, I'll push
>> the hcidump log out as well. Because the failure occurs during eSCO
>> negotiation and SCO request with the remote, most of the interesting
>> stuff is in LMP, so I'll include the FTS sniffer trace as well.
>
> don't bother with FTS traces. I don't care. I just need to see the
> output of hcidump -X -V so that I can figure out what the problem is
> here and what are possible solutions. Send the hcidump now before
> redoing the patches.
>
> Regards
>
> Marcel
>
>
Here's the hcidump for this scenario. I've also taken a look at the ACL retry
mechanism used in the case where the baseband is too busy and the connection
attempt fails. The same mechanism is already in place for SCO and eSCO. The
difference with this particular scenario is this:
1. The failure is caused be an issue on the remote
2. Once the failure has occurred it is generally unrecoverable i.e. the remote
side is hosed and needs to be reset, so repeated attempts continue to fail.
3. The only way to make a successful connection and keep from hosing the remote
is to prevent the scenario from occurring by not requesting eSCO or SCO during
the transition period.
As for hold and park, we can generalize it by making eSCO or SCO pend
until we also exit from hold. As for park, it's unclear as I didn't really
see any support for park. It doesn't look like we prevent commands or data
from being sent to a remote that is parked.
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
Error: Connection Accept Timeout Exceeded
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
< ACL data: handle 12 flags 0x00 dlen 22
0000: 12 00 41 00 0b ef 1d 0d 0a 2b 43 49 45 56 3a 20 ..A..ï...+CIEV:
0010: 35 2c 34 0d 0a 9a 5,4...
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
< ACL data: handle 12 flags 0x00 dlen 22
0000: 12 00 41 00 0b ef 1d 0d 0a 2b 43 49 45 56 3a 20 ..A..ï...+CIEV:
0010: 35 2c 35 0d 0a 9a 5,5...
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
Error: Connection Accept Timeout Exceeded
--
Ron Shaffer
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* RE: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Perelet, Oleg @ 2010-05-27 3:38 UTC (permalink / raw)
To: Ron Shaffer, Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4BFD98F0.5090203@codeaurora.org>
Marcel, Here's some prehistory of this patch. 1st Nick did:
http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff;h=201ac2f225a31dffcb05f1db4d609c467c9c694c
which unsniffs connection before doing SCO, otherwise establishing SCO took few seconds on some headsets. Then this patch broke whole bunch of headsets that expected SCO only after unsiff is Acked - that what Ron did.
I had email conversation with Nick about that. IMHO this logic belongs to user land, but because of GPL/Apache conflict libbluetooth can not be lifted in to Android Java/JNI - that's why initial change went to kernel.
If you guys can have some clever way of doing it in bluetoothd - nice. Otherwise this gargantuan kernel patch does fix the problem
Oleg.
PS. Sorry if this email conflicts with top posting rules, that's my email client of this moment. I'll buy you sushi:)
^ permalink raw reply
* RE: [PATCH 1/1] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Marcel Holtmann @ 2010-05-27 10:34 UTC (permalink / raw)
To: Perelet, Oleg; +Cc: Ron Shaffer, linux-bluetooth@vger.kernel.org
In-Reply-To: <BCDE476F204B134B8B235FB275BC3AD805E55D3D3D@NALASEXMB01.na.qualcomm.com>
Hi Oleg,
> Marcel, Here's some prehistory of this patch. 1st Nick did:
>
> http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff;h=201ac2f225a31dffcb05f1db4d609c467c9c694c
>
> which unsniffs connection before doing SCO, otherwise establishing SCO took few seconds on some headsets. Then this patch broke whole bunch of headsets that expected SCO only after unsiff is Acked - that what Ron did.
>
> I had email conversation with Nick about that. IMHO this logic belongs to user land, but because of GPL/Apache conflict libbluetooth can not be lifted in to Android Java/JNI - that's why initial change went to kernel.
>
> If you guys can have some clever way of doing it in bluetoothd - nice. Otherwise this gargantuan kernel patch does fix the problem
I am fine with doing this inside the kernel. It makes perfect sense, but
it needs to be aligned a little bit with the overall way on how we
handle connection setup.
My main question was if it a retry because of failure or if we
preemptively wait until we are in active mode. And that got answered
since the headsets will lock up if we even try.
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox