* [A2DP] Incoming connections do not succeed
@ 2014-07-26 1:33 Artem Rakhov
2014-07-28 8:21 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 25+ messages in thread
From: Artem Rakhov @ 2014-07-26 1:33 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I have a problem with A2DP incoming connections. I have a BT speaker
(Monster Clarity HD), which automatically reconnects on startup to the
last connected source. It works fine with BlueZ 4, but it never
reconnects successfully when using BlueZ 5.19
Here is btmon log:
< ACL Data TX: Handle 21 flags 0x00 dlen 16
[hci0] 3471.224113
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 108
Result: Connection pending (0x0001)
Status: Authorization pending (0x0002)
< ACL Data TX: Handle 21 flags 0x00 dlen 16
[hci0] 3471.224313
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 108
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 21 flags 0x00 dlen 12
[hci0] 3471.224417
L2CAP: Configure Request (0x04) ident 2 len 4
Destination CID: 108
Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.226831
Num handles: 1
Handle: 21
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.227794
Num handles: 1
Handle: 21
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.228807
Num handles: 1
Handle: 21
Count: 1
> ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 3471.256507
L2CAP: Disconnection Request (0x06) ident 3 len 4
Destination CID: 64
Source CID: 108
< ACL Data TX: Handle 21 flags 0x00 dlen 12
[hci0] 3471.256592
L2CAP: Disconnection Response (0x07) ident 3 len 4
Destination CID: 64
Source CID: 108
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.258773
Num handles: 1
Handle: 21
Count: 1
> HCI Event: Vendor (0xff) plen 7 [hci0] 3471.549833
82 00 01 00 01 15 00 .......
> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 3471.550757
Status: Success (0x00)
Handle: 21
Reason: Remote User Terminated Connection (0x13)
@ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3
As could be seen from the log, after the source sends L2CAP Configure
Request the speaker does not answer and disconnects (sends L2CAP
Disconnection Request).
Debugging avdtp.c showed that processing of incoming connections is
held in avdtp_confirm_cb() function. There, at some point after
successful authorization G_IO_ERR and G_IO_HUP events appear. And then
session_cb() function is called (as callback for these events), which
drops the connection.
Does anyone experience the same issue or have any ideas on how to fix it?
Thanks,
Artem
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [A2DP] Incoming connections do not succeed 2014-07-26 1:33 [A2DP] Incoming connections do not succeed Artem Rakhov @ 2014-07-28 8:21 ` Luiz Augusto von Dentz 2014-07-29 0:24 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-07-28 8:21 UTC (permalink / raw) To: Artem Rakhov; +Cc: linux-bluetooth Hi Artem, On Sat, Jul 26, 2014 at 4:33 AM, Artem Rakhov <arakhov@chromium.org> wrote: > Hello, > > I have a problem with A2DP incoming connections. I have a BT speaker > (Monster Clarity HD), which automatically reconnects on startup to the > last connected source. It works fine with BlueZ 4, but it never > reconnects successfully when using BlueZ 5.19 > > Here is btmon log: > < ACL Data TX: Handle 21 flags 0x00 dlen 16 > [hci0] 3471.224113 > L2CAP: Connection Response (0x03) ident 2 len 8 > Destination CID: 64 > Source CID: 108 > Result: Connection pending (0x0001) > Status: Authorization pending (0x0002) > < ACL Data TX: Handle 21 flags 0x00 dlen 16 > [hci0] 3471.224313 > L2CAP: Connection Response (0x03) ident 2 len 8 > Destination CID: 64 > Source CID: 108 > Result: Connection successful (0x0000) > Status: No further information available (0x0000) > < ACL Data TX: Handle 21 flags 0x00 dlen 12 > [hci0] 3471.224417 > L2CAP: Configure Request (0x04) ident 2 len 4 > Destination CID: 108 > Flags: 0x0000 >> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.226831 > Num handles: 1 > Handle: 21 > Count: 1 >> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.227794 > Num handles: 1 > Handle: 21 > Count: 1 >> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.228807 > Num handles: 1 > Handle: 21 > Count: 1 >> ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 3471.256507 > L2CAP: Disconnection Request (0x06) ident 3 len 4 > Destination CID: 64 > Source CID: 108 > < ACL Data TX: Handle 21 flags 0x00 dlen 12 > [hci0] 3471.256592 > L2CAP: Disconnection Response (0x07) ident 3 len 4 > Destination CID: 64 > Source CID: 108 >> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.258773 > Num handles: 1 > Handle: 21 > Count: 1 >> HCI Event: Vendor (0xff) plen 7 [hci0] 3471.549833 > 82 00 01 00 01 15 00 ....... >> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 3471.550757 > Status: Success (0x00) > Handle: 21 > Reason: Remote User Terminated Connection (0x13) > @ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3 > > > As could be seen from the log, after the source sends L2CAP Configure > Request the speaker does not answer and disconnects (sends L2CAP > Disconnection Request). > > Debugging avdtp.c showed that processing of incoming connections is > held in avdtp_confirm_cb() function. There, at some point after > successful authorization G_IO_ERR and G_IO_HUP events appear. And then > session_cb() function is called (as callback for these events), which > drops the connection. This looks pretty strange as the remote seems to be disconnecting not us, btw did you tried to mark the device as trusted? Regarding it working with BlueZ 4, what kernel are you using with that and can you try to compare what is the difference in the logs, perhaps the remote does like the Configure Request for some reason. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-07-28 8:21 ` Luiz Augusto von Dentz @ 2014-07-29 0:24 ` Artem Rakhov 2014-07-29 5:16 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-07-29 0:24 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hi Luiz, Yes, the device is trusted. So far I've tried BlueZ 4 with kernel 3.13, and Bluez 5.19 with kernel 3.8.11 Thanks, Artem On Mon, Jul 28, 2014 at 1:21 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Artem, > > On Sat, Jul 26, 2014 at 4:33 AM, Artem Rakhov <arakhov@chromium.org> wrote: >> Hello, >> >> I have a problem with A2DP incoming connections. I have a BT speaker >> (Monster Clarity HD), which automatically reconnects on startup to the >> last connected source. It works fine with BlueZ 4, but it never >> reconnects successfully when using BlueZ 5.19 >> >> Here is btmon log: >> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >> [hci0] 3471.224113 >> L2CAP: Connection Response (0x03) ident 2 len 8 >> Destination CID: 64 >> Source CID: 108 >> Result: Connection pending (0x0001) >> Status: Authorization pending (0x0002) >> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >> [hci0] 3471.224313 >> L2CAP: Connection Response (0x03) ident 2 len 8 >> Destination CID: 64 >> Source CID: 108 >> Result: Connection successful (0x0000) >> Status: No further information available (0x0000) >> < ACL Data TX: Handle 21 flags 0x00 dlen 12 >> [hci0] 3471.224417 >> L2CAP: Configure Request (0x04) ident 2 len 4 >> Destination CID: 108 >> Flags: 0x0000 >>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.226831 >> Num handles: 1 >> Handle: 21 >> Count: 1 >>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.227794 >> Num handles: 1 >> Handle: 21 >> Count: 1 >>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.228807 >> Num handles: 1 >> Handle: 21 >> Count: 1 >>> ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 3471.256507 >> L2CAP: Disconnection Request (0x06) ident 3 len 4 >> Destination CID: 64 >> Source CID: 108 >> < ACL Data TX: Handle 21 flags 0x00 dlen 12 >> [hci0] 3471.256592 >> L2CAP: Disconnection Response (0x07) ident 3 len 4 >> Destination CID: 64 >> Source CID: 108 >>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.258773 >> Num handles: 1 >> Handle: 21 >> Count: 1 >>> HCI Event: Vendor (0xff) plen 7 [hci0] 3471.549833 >> 82 00 01 00 01 15 00 ....... >>> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 3471.550757 >> Status: Success (0x00) >> Handle: 21 >> Reason: Remote User Terminated Connection (0x13) >> @ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3 >> >> >> As could be seen from the log, after the source sends L2CAP Configure >> Request the speaker does not answer and disconnects (sends L2CAP >> Disconnection Request). >> >> Debugging avdtp.c showed that processing of incoming connections is >> held in avdtp_confirm_cb() function. There, at some point after >> successful authorization G_IO_ERR and G_IO_HUP events appear. And then >> session_cb() function is called (as callback for these events), which >> drops the connection. > > This looks pretty strange as the remote seems to be disconnecting not > us, btw did you tried to mark the device as trusted? Regarding it > working with BlueZ 4, what kernel are you using with that and can you > try to compare what is the difference in the logs, perhaps the remote > does like the Configure Request for some reason. > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-07-29 0:24 ` Artem Rakhov @ 2014-07-29 5:16 ` Artem Rakhov 2014-07-29 5:29 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-07-29 5:16 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Have tried to connect the speaker to Macbook Pro (OS X, does not use BlueZ). For some reason, when speaker initiates the incoming connection, it connects via L2CAP to different PSM. First, it goes to PSM 0x01 (Service Discovery Protocol), then disconnects. Then it connects to 0x03 (RFCOMM) and keeps the connection. After that speaker connects to PSM 0x01 again, and drops connection. And then finally the Mac itself initiates two L2CAP connections to speaker, with correct PSM 0x19 (AVDTP). On device with BlueZ L2CAP connection goes straight to PSM 0x19. Here is a log from Macbook for the first connection to AVDTP: [Jul 28 21:06:37.848] [L2CAP SEND] Connection Request - PSM: 0x0019 Connection Request - PSM: 0x0019 Identifier: 0x81 Size: 4 (0x0004) PSM: 0x0019 - AVDTP (Audio/Video Distribution Transport Protocol). Source CID: 0x0043 Channel ID: 0x0001 Length: 0x0008 (08) [ 0B 20 0C 00 08 00 01 00 ] 00000000: 0800 0100 0281 0400 1900 4300 ..........C. [Jul 28 21:06:37.848] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x000C (12)] [Jul 28 21:06:37.849] [HCI COMMAND] [FC48] Vendor Specific Command [FC48] - Read Raw RSSI [Jul 28 21:06:37.851] [HCI EVENT] [FC48] Command Complete - Broadcom VSC Event - Read Raw RSSI - Handle: 0x000B -50 dBm [Jul 28 21:06:37.877] [L2CAP RECEIVE] Connection Response Connection Response Identifier: 0x81 Size: 8 (0x0008) Destination CID: 0x0043 Source CID: 0x0043 Result: 0x0001 (Connection Pending) Status: 0x0002 (Authorization Pending) Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 03 81 08 00 ] 00000000: 0c00 0100 0381 0800 4300 4300 0100 0200 ........C.C..... [Jul 28 21:06:37.877] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:37.986] [L2CAP RECEIVE] Connection Response Connection Response Identifier: 0x81 Size: 8 (0x0008) Destination CID: 0x0043 Source CID: 0x0043 Result: 0x0000 (Connection Successful) Status: 0x0000 (No further information available) Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 03 81 08 00 ] 00000000: 0c00 0100 0381 0800 4300 4300 0000 0000 ........C.C..... [Jul 28 21:06:37.986] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:37.986] [L2CAP SEND] Configuration Request Configuration Request Identifier: 0x84 Size: 8 (0x0008) Destination CID: 0x0043 Flags: 0x0000 - Not Continuation Options: Type: 0x01 (Hint) Length: 0x02 MTU: 0xFFFF Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 04 84 08 00 ] 00000000: 0c00 0100 0484 0800 4300 0000 0102 ffff ........C....... [Jul 28 21:06:37.986] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:37.987] [L2CAP RECEIVE] Configuration Request Configuration Request Identifier: 0x0a Size: 8 (0x0008) Destination CID: 0x0043 Flags: 0x0000 - Not Continuation Options: Type: 0x01 (Hint) Length: 0x02 MTU: 0x037F Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 04 0A 08 00 ] 00000000: 0c00 0100 040a 0800 4300 0000 0102 7f03 ........C....... [Jul 28 21:06:37.987] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:37.987] [L2CAP SEND] Configure Response Configure Response Identifier: 0x0a Size: 10 (0x000A) Source CID: 0x0043 Flags: 0x0000 - Not Continuation Result: 0x0000 Success Config: Type: 0x01 (Hint) Length: 0x02 MTU: 0x037F Channel ID: 0x0001 Length: 0x000E (14) [ 0B 20 12 00 0E 00 01 00 05 0A 0A 00 43 00 ] 00000000: 0e00 0100 050a 0a00 4300 0000 0000 0102 ........C....... 00000010: 7f03 .. [Jul 28 21:06:37.987] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0012 (18)] [Jul 28 21:06:37.991] [HCI EVENT] Number of Completed Packets - Connection Handle: 0x000B - Packets: 0x0002 [Jul 28 21:06:38.020] [L2CAP RECEIVE] Configure Response Configure Response Identifier: 0x84 Size: 6 (0x0006) Source CID: 0x0043 Flags: 0x0000 - Not Continuation Result: 0x0000 Success Empty Config Response. Channel ID: 0x0001 Length: 0x000A (10) [ 0B 20 0E 00 0A 00 01 00 05 84 ] 00000000: 0a00 0100 0584 0600 4300 0000 0000 ........C..... [Jul 28 21:06:38.020] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x000E (14)] [Jul 28 21:06:38.020] [AVDTP SEND] Discover: Signal (0x01) [Jul 28 21:06:38.024] [HCI EVENT] Number of Completed Packets - Connection Handle: 0x000B - Packets: 0x0002 [Jul 28 21:06:38.077] [AVDTP RECEIVE] Discover: Accept-Response (0x01) [Jul 28 21:06:38.178] [AVDTP SEND] Get Cap.: Signal (0x02) ... Log for the second connection: [Jul 28 21:06:38.519] [L2CAP SEND] Connection Request - PSM: 0x0019 Connection Request - PSM: 0x0019 Identifier: 0x14 Size: 4 (0x0004) PSM: 0x0019 - AVDTP (Audio/Video Distribution Transport Protocol). Source CID: 0x0044 Channel ID: 0x0001 Length: 0x0008 (08) [ 0B 20 0C 00 08 00 01 00 ] 00000000: 0800 0100 0214 0400 1900 4400 ..........D. [Jul 28 21:06:38.519] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x000C (12)] [Jul 28 21:06:38.520] [HCI COMMAND] [FC48] Vendor Specific Command [FC48] - Read Raw RSSI [Jul 28 21:06:38.521] [HCI EVENT] [FC48] Command Complete - Broadcom VSC Event - Read Raw RSSI - Handle: 0x000B -48 dBm [Jul 28 21:06:38.550] [L2CAP RECEIVE] Connection Response Connection Response Identifier: 0x14 Size: 8 (0x0008) Destination CID: 0x0044 Source CID: 0x0044 Result: 0x0001 (Connection Pending) Status: 0x0002 (Authorization Pending) Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 03 14 08 00 ] 00000000: 0c00 0100 0314 0800 4400 4400 0100 0200 ........D.D..... [Jul 28 21:06:38.550] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:38.608] [L2CAP RECEIVE] Connection Response Connection Response Identifier: 0x14 Size: 8 (0x0008) Destination CID: 0x0044 Source CID: 0x0044 Result: 0x0000 (Connection Successful) Status: 0x0000 (No further information available) Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 03 14 08 00 ] 00000000: 0c00 0100 0314 0800 4400 4400 0000 0000 ........D.D..... [Jul 28 21:06:38.608] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:38.608] [L2CAP SEND] Configuration Request Configuration Request Identifier: 0x3d Size: 8 (0x0008) Destination CID: 0x0044 Flags: 0x0000 - Not Continuation Options: Type: 0x01 (Hint) Length: 0x02 MTU: 0xFFFF Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 04 3D 08 00 ] 00000000: 0c00 0100 043d 0800 4400 0000 0102 ffff .....=..D....... [Jul 28 21:06:38.608] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:38.611] [HCI EVENT] Number of Completed Packets - Connection Handle: 0x000B - Packets: 0x0002 [Jul 28 21:06:38.640] [L2CAP RECEIVE] Configuration Request Configuration Request Identifier: 0x0b Size: 8 (0x0008) Destination CID: 0x0044 Flags: 0x0000 - Not Continuation Options: Type: 0x01 (Hint) Length: 0x02 MTU: 0x037F Channel ID: 0x0001 Length: 0x000C (12) [ 0B 20 10 00 0C 00 01 00 04 0B 08 00 ] 00000000: 0c00 0100 040b 0800 4400 0000 0102 7f03 ........D....... [Jul 28 21:06:38.640] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0010 (16)] [Jul 28 21:06:38.640] [L2CAP SEND] Configure Response Configure Response Identifier: 0x0b Size: 10 (0x000A) Source CID: 0x0044 Flags: 0x0000 - Not Continuation Result: 0x0000 Success Config: Type: 0x01 (Hint) Length: 0x02 MTU: 0x037F Channel ID: 0x0001 Length: 0x000E (14) [ 0B 20 12 00 0E 00 01 00 05 0B 0A 00 44 00 ] 00000000: 0e00 0100 050b 0a00 4400 0000 0000 0102 ........D....... 00000010: 7f03 .. [Jul 28 21:06:38.640] [ACL SEND] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x0012 (18)] [Jul 28 21:06:38.641] [L2CAP RECEIVE] Configure Response Configure Response Identifier: 0x3d Size: 6 (0x0006) Source CID: 0x0044 Flags: 0x0000 - Not Continuation Result: 0x0000 Success Empty Config Response. Channel ID: 0x0001 Length: 0x000A (10) [ 0B 20 0E 00 0A 00 01 00 05 3D ] 00000000: 0a00 0100 053d 0600 4400 0000 0000 .....=..D..... [Jul 28 21:06:38.641] [ACL RECEIVE] Data [Handle: 0x000B, Packet Boundary Flags: 0x2, Length: 0x000E (14)] Another observation is that BlueZ's L2CAP Configure Request does not contain any MTU. Is that normal? Thanks, Artem On Mon, Jul 28, 2014 at 5:24 PM, Artem Rakhov <arakhov@chromium.org> wrote: > Hi Luiz, > > Yes, the device is trusted. > So far I've tried BlueZ 4 with kernel 3.13, and Bluez 5.19 with kernel 3.8.11 > > Thanks, > Artem > > On Mon, Jul 28, 2014 at 1:21 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> Hi Artem, >> >> On Sat, Jul 26, 2014 at 4:33 AM, Artem Rakhov <arakhov@chromium.org> wrote: >>> Hello, >>> >>> I have a problem with A2DP incoming connections. I have a BT speaker >>> (Monster Clarity HD), which automatically reconnects on startup to the >>> last connected source. It works fine with BlueZ 4, but it never >>> reconnects successfully when using BlueZ 5.19 >>> >>> Here is btmon log: >>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>> [hci0] 3471.224113 >>> L2CAP: Connection Response (0x03) ident 2 len 8 >>> Destination CID: 64 >>> Source CID: 108 >>> Result: Connection pending (0x0001) >>> Status: Authorization pending (0x0002) >>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>> [hci0] 3471.224313 >>> L2CAP: Connection Response (0x03) ident 2 len 8 >>> Destination CID: 64 >>> Source CID: 108 >>> Result: Connection successful (0x0000) >>> Status: No further information available (0x0000) >>> < ACL Data TX: Handle 21 flags 0x00 dlen 12 >>> [hci0] 3471.224417 >>> L2CAP: Configure Request (0x04) ident 2 len 4 >>> Destination CID: 108 >>> Flags: 0x0000 >>>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.226831 >>> Num handles: 1 >>> Handle: 21 >>> Count: 1 >>>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.227794 >>> Num handles: 1 >>> Handle: 21 >>> Count: 1 >>>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.228807 >>> Num handles: 1 >>> Handle: 21 >>> Count: 1 >>>> ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 3471.256507 >>> L2CAP: Disconnection Request (0x06) ident 3 len 4 >>> Destination CID: 64 >>> Source CID: 108 >>> < ACL Data TX: Handle 21 flags 0x00 dlen 12 >>> [hci0] 3471.256592 >>> L2CAP: Disconnection Response (0x07) ident 3 len 4 >>> Destination CID: 64 >>> Source CID: 108 >>>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 3471.258773 >>> Num handles: 1 >>> Handle: 21 >>> Count: 1 >>>> HCI Event: Vendor (0xff) plen 7 [hci0] 3471.549833 >>> 82 00 01 00 01 15 00 ....... >>>> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 3471.550757 >>> Status: Success (0x00) >>> Handle: 21 >>> Reason: Remote User Terminated Connection (0x13) >>> @ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3 >>> >>> >>> As could be seen from the log, after the source sends L2CAP Configure >>> Request the speaker does not answer and disconnects (sends L2CAP >>> Disconnection Request). >>> >>> Debugging avdtp.c showed that processing of incoming connections is >>> held in avdtp_confirm_cb() function. There, at some point after >>> successful authorization G_IO_ERR and G_IO_HUP events appear. And then >>> session_cb() function is called (as callback for these events), which >>> drops the connection. >> >> This looks pretty strange as the remote seems to be disconnecting not >> us, btw did you tried to mark the device as trusted? Regarding it >> working with BlueZ 4, what kernel are you using with that and can you >> try to compare what is the difference in the logs, perhaps the remote >> does like the Configure Request for some reason. >> >> >> -- >> Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-07-29 5:16 ` Artem Rakhov @ 2014-07-29 5:29 ` Marcel Holtmann 2014-08-08 7:32 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Marcel Holtmann @ 2014-07-29 5:29 UTC (permalink / raw) To: Artem Rakhov; +Cc: Luiz Augusto von Dentz, linux-bluetooth Hi Artem, > Have tried to connect the speaker to Macbook Pro (OS X, does not use > BlueZ). For some reason, when speaker initiates the incoming > connection, it connects via L2CAP to different PSM. > First, it goes to PSM 0x01 (Service Discovery Protocol), then > disconnects. Then it connects to 0x03 (RFCOMM) and keeps the > connection. After that speaker connects to PSM 0x01 again, and drops > connection. > And then finally the Mac itself initiates two L2CAP connections to > speaker, with correct PSM 0x19 (AVDTP). On device with BlueZ L2CAP > connection goes straight to PSM 0x19. > > Here is a log from Macbook for the first connection to AVDTP: > [Jul 28 21:06:37.848] [L2CAP SEND] Connection Request - PSM: 0x0019 > Connection Request - PSM: 0x0019 > Identifier: 0x81 > Size: 4 (0x0004) > PSM: 0x0019 - AVDTP (Audio/Video Distribution Transport > Protocol). > Source CID: 0x0043 > Channel ID: 0x0001 Length: 0x0008 (08) [ 0B 20 0C 00 > 08 00 01 00 ] > 00000000: 0800 0100 0281 0400 1900 4300 ..........C. you know that hcidump and btmon can read Packet Logger files created on OS X. So maybe sending a binary pklg file around might be helpful for anybody looking at the details here. Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-07-29 5:29 ` Marcel Holtmann @ 2014-08-08 7:32 ` Artem Rakhov 2014-08-10 7:32 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-08 7:32 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Luiz Augusto von Dentz, linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 2287 bytes --] Hi Marcel, Please find Packet Logger's btsnoop log in the attachment. So far I have 2 observations: 1. Mac does not require any authorization (most likely it's not the cause) 2. I found another BT speaker which works properly. At first, I'm seeing the same behavior: speaker initiates connection, BlueZ sends Configure Request (with no MTU), then speaker disconnects. But after that the device tries to initiate connection for the second time, and this time it is successful: after BlueZ sends Configure Request with no MTU, speaker answers with another Configure Request (with some MTU), and connection is established normally. Is it possible, that BlueZ is doing something wrong, but then this new speaker tries something else, while the old one does not? I also tried kernel 3.10 and latest BlueZ, it didn't change anything. Thanks, Artem On Mon, Jul 28, 2014 at 10:29 PM, Marcel Holtmann <marcel@holtmann.org> wrote: > Hi Artem, > >> Have tried to connect the speaker to Macbook Pro (OS X, does not use >> BlueZ). For some reason, when speaker initiates the incoming >> connection, it connects via L2CAP to different PSM. >> First, it goes to PSM 0x01 (Service Discovery Protocol), then >> disconnects. Then it connects to 0x03 (RFCOMM) and keeps the >> connection. After that speaker connects to PSM 0x01 again, and drops >> connection. >> And then finally the Mac itself initiates two L2CAP connections to >> speaker, with correct PSM 0x19 (AVDTP). On device with BlueZ L2CAP >> connection goes straight to PSM 0x19. >> >> Here is a log from Macbook for the first connection to AVDTP: >> [Jul 28 21:06:37.848] [L2CAP SEND] Connection Request - PSM: 0x0019 >> Connection Request - PSM: 0x0019 >> Identifier: 0x81 >> Size: 4 (0x0004) >> PSM: 0x0019 - AVDTP (Audio/Video Distribution Transport >> Protocol). >> Source CID: 0x0043 >> Channel ID: 0x0001 Length: 0x0008 (08) [ 0B 20 0C 00 >> 08 00 01 00 ] >> 00000000: 0800 0100 0281 0400 1900 4300 ..........C. > > you know that hcidump and btmon can read Packet Logger files created on OS X. So maybe sending a binary pklg file around might be helpful for anybody looking at the details here. > > Regards > > Marcel > [-- Attachment #2: bluetooth_packet.btsnoop --] [-- Type: application/octet-stream, Size: 15436 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-08 7:32 ` Artem Rakhov @ 2014-08-10 7:32 ` Luiz Augusto von Dentz 2014-08-11 6:07 ` Michal Labedzki 2014-08-18 7:11 ` Artem Rakhov 0 siblings, 2 replies; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-08-10 7:32 UTC (permalink / raw) To: Artem Rakhov; +Cc: Marcel Holtmann, linux-bluetooth Hi Artem, On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> wrote: > Hi Marcel, > > Please find Packet Logger's btsnoop log in the attachment. > > So far I have 2 observations: > 1. Mac does not require any authorization (most likely it's not the cause) > 2. I found another BT speaker which works properly. At first, I'm > seeing the same behavior: speaker initiates connection, BlueZ sends > Configure Request (with no MTU), then speaker disconnects. But after > that the device tries to initiate connection for the second time, and > this time it is successful: after BlueZ sends Configure Request with > no MTU, speaker answers with another Configure Request (with some > MTU), and connection is established normally. Is it possible, that > BlueZ is doing something wrong, but then this new speaker tries > something else, while the old one does not? I could not find anything l2cap related in this logs, but I notice there a LE scanning ongoing perhaps you have should try disabling it with Disconnect method for now. Anyway A2DP code is not really involved with L2CAP connection setup so we would have to look at the kernel changes but I quick check doesn't show anything and you said you have tried with 3.10 so Im afraid this is only reproducible with some specific device. Btw, if you want to really isolate the problem you can try to connect using avinfo or l2test directly. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-10 7:32 ` Luiz Augusto von Dentz @ 2014-08-11 6:07 ` Michal Labedzki 2014-08-18 7:11 ` Artem Rakhov 1 sibling, 0 replies; 25+ messages in thread From: Michal Labedzki @ 2014-08-11 6:07 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Artem Rakhov, Marcel Holtmann, linux-bluetooth Hi Luiz, > I could not find anything l2cap related in this logs See frame 258. It seems to be HFP. However log file seems to be broken or... btmon and Wireshark have broken support for H1 (direction [Sent/Recv] seems to be correct in logs, but Channel type is not [btmon/wireshark treat 0 as ACL, 1 as HCI? little strange...]). On 10 August 2014 09:32, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrot= e: > Hi Artem, > > On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> wrot= e: >> Hi Marcel, >> >> Please find Packet Logger's btsnoop log in the attachment. >> >> So far I have 2 observations: >> 1. Mac does not require any authorization (most likely it's not the caus= e) >> 2. I found another BT speaker which works properly. At first, I'm >> seeing the same behavior: speaker initiates connection, BlueZ sends >> Configure Request (with no MTU), then speaker disconnects. But after >> that the device tries to initiate connection for the second time, and >> this time it is successful: after BlueZ sends Configure Request with >> no MTU, speaker answers with another Configure Request (with some >> MTU), and connection is established normally. Is it possible, that >> BlueZ is doing something wrong, but then this new speaker tries >> something else, while the old one does not? > > I could not find anything l2cap related in this logs, but I notice > there a LE scanning ongoing perhaps you have should try disabling it > with Disconnect method for now. Anyway A2DP code is not really > involved with L2CAP connection setup so we would have to look at the > kernel changes but I quick check doesn't show anything and you said > you have tried with 3.10 so Im afraid this is only reproducible with > some specific device. > > Btw, if you want to really isolate the problem you can try to connect > using avinfo or l2test directly. > > > -- > Luiz Augusto von Dentz > -- > 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 --=20 Pozdrawiam / Best regards ---------------------------------------------------------------------------= ---------------------------------- Micha=C5=82 =C5=81ab=C4=99dzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wroc=C5=82aw, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland sp=C3=B3=C5=82ka z ograniczon=C4=85 odpowiedzialno=C5=9Bci=C4= =85 z siedzib=C4=85 w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w S=C4=85dzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydzia=C5=82 Gospodarczy Krajowego Rejestru S=C4=85dowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapita=C5=82 zak=C5=82adowy: 4 271500 PLN ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-10 7:32 ` Luiz Augusto von Dentz 2014-08-11 6:07 ` Michal Labedzki @ 2014-08-18 7:11 ` Artem Rakhov 2014-08-20 22:52 ` Artem Rakhov 2014-08-20 22:54 ` Artem Rakhov 1 sibling, 2 replies; 25+ messages in thread From: Artem Rakhov @ 2014-08-18 7:11 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth Hi Luiz, I have also tried kernel 3.14, it didn't help. How can I use avinfo for test? Looks like it shows only basic information for the device. And it works fine with the speaker. I tried to use avtest: when I try to connect to the speaker, everything seems to be working good. Is there any way to use it to test incoming connections? Thanks, Artem On Sun, Aug 10, 2014 at 12:32 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Artem, > > On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> wrote: >> Hi Marcel, >> >> Please find Packet Logger's btsnoop log in the attachment. >> >> So far I have 2 observations: >> 1. Mac does not require any authorization (most likely it's not the cause) >> 2. I found another BT speaker which works properly. At first, I'm >> seeing the same behavior: speaker initiates connection, BlueZ sends >> Configure Request (with no MTU), then speaker disconnects. But after >> that the device tries to initiate connection for the second time, and >> this time it is successful: after BlueZ sends Configure Request with >> no MTU, speaker answers with another Configure Request (with some >> MTU), and connection is established normally. Is it possible, that >> BlueZ is doing something wrong, but then this new speaker tries >> something else, while the old one does not? > > I could not find anything l2cap related in this logs, but I notice > there a LE scanning ongoing perhaps you have should try disabling it > with Disconnect method for now. Anyway A2DP code is not really > involved with L2CAP connection setup so we would have to look at the > kernel changes but I quick check doesn't show anything and you said > you have tried with 3.10 so Im afraid this is only reproducible with > some specific device. > > Btw, if you want to really isolate the problem you can try to connect > using avinfo or l2test directly. > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-18 7:11 ` Artem Rakhov @ 2014-08-20 22:52 ` Artem Rakhov 2014-08-20 22:54 ` Artem Rakhov 1 sibling, 0 replies; 25+ messages in thread From: Artem Rakhov @ 2014-08-20 22:52 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth [-- Attachment #1.1: Type: text/plain, Size: 2578 bytes --] Hello, I found the way to use avtest for testing incoming connections from the speaker. If anyone is interested: stopped bluetoothd, powered BT back to on, used "avtest --reject 0". Also had to change avtest to answer like source instead of sink, which is set by default. Incoming connections to avtest are always successful. And logs are very similar (attached). I think the main difference is that the bluetoothd requires authorization, while avtest does not. Thanks, Artem On Mon, Aug 18, 2014 at 12:11 AM, Artem Rakhov <arakhov@chromium.org> wrote: > Hi Luiz, > > I have also tried kernel 3.14, it didn't help. > How can I use avinfo for test? Looks like it shows only basic > information for the device. And it works fine with the speaker. > I tried to use avtest: when I try to connect to the speaker, > everything seems to be working good. Is there any way to use it to > test incoming connections? > > Thanks, > Artem > > On Sun, Aug 10, 2014 at 12:32 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > Hi Artem, > > > > On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> > wrote: > >> Hi Marcel, > >> > >> Please find Packet Logger's btsnoop log in the attachment. > >> > >> So far I have 2 observations: > >> 1. Mac does not require any authorization (most likely it's not the > cause) > >> 2. I found another BT speaker which works properly. At first, I'm > >> seeing the same behavior: speaker initiates connection, BlueZ sends > >> Configure Request (with no MTU), then speaker disconnects. But after > >> that the device tries to initiate connection for the second time, and > >> this time it is successful: after BlueZ sends Configure Request with > >> no MTU, speaker answers with another Configure Request (with some > >> MTU), and connection is established normally. Is it possible, that > >> BlueZ is doing something wrong, but then this new speaker tries > >> something else, while the old one does not? > > > > I could not find anything l2cap related in this logs, but I notice > > there a LE scanning ongoing perhaps you have should try disabling it > > with Disconnect method for now. Anyway A2DP code is not really > > involved with L2CAP connection setup so we would have to look at the > > kernel changes but I quick check doesn't show anything and you said > > you have tried with 3.10 so Im afraid this is only reproducible with > > some specific device. > > > > Btw, if you want to really isolate the problem you can try to connect > > using avinfo or l2test directly. > > > > > > -- > > Luiz Augusto von Dentz > [-- Attachment #1.2: Type: text/html, Size: 3420 bytes --] [-- Attachment #2: btmon_avtest --] [-- Type: application/octet-stream, Size: 18928 bytes --] luetooth monitor ver 5.19 = New Index: 3C:77:E6:60:5C:B2 (BR/EDR,USB,hci0) [hci0] 0.456259 > HCI Event: Vendor (0xff) plen 2 [hci0] 22.527472 81 00 .. > HCI Event: Connect Request (0x04) plen 10 [hci0] 22.528472 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 [hci0] 22.528565 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Slave (0x01) > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.529462 Accept Connection Request (0x01|0x0009) ncmd 1 Status: Success (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 22.576536 81 01 .. > HCI Event: Vendor (0xff) plen 7 [hci0] 22.577469 82 00 00 01 01 15 00 ....... > HCI Event: Connect Complete (0x03) plen 11 [hci0] 22.578469 Status: Success (0x00) Handle: 21 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 [hci0] 22.578641 Handle: 21 > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.579463 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Supported Features (0x0b) plen 11 [hci0] 22.605538 Status: Success (0x00) Handle: 21 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Extended features < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 [hci0] 22.605584 Handle: 21 Page: 1 > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.606460 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Extended Features (0x23) plen 13 [hci0] 22.615477 Status: Success (0x00) Handle: 21 Page: 1/1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) < HCI Command: Remote Name Request (0x01|0x0019) plen 10 [hci0] 22.615583 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 > HCI Event: Vendor (0xff) plen 2 [hci0] 22.616462 81 00 .. > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.617463 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Link Key Request (0x17) plen 6 [hci0] 22.654535 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 [hci0] 22.654580 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link key: 9a1e116ffd4baad792d15c680b35f152 > HCI Event: Command Complete (0x0e) plen 10 [hci0] 22.657473 Link Key Request Reply (0x01|0x000b) ncmd 1 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) > HCI Event: Vendor (0xff) plen 2 [hci0] 22.659466 81 01 .. > HCI Event: Remote Name Req Complete (0x07) plen 255 [hci0] 22.676479 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Name: Monster Clarity @ Device Connected: 10:B7:F6:01:31:ED (0) flags 0x0000 10 09 4d 6f 6e 73 74 65 72 20 43 6c 61 72 69 74 ..Monster Clarit 79 04 0d 04 04 24 y....$ > HCI Event: Encryption Change (0x08) plen 4 [hci0] 22.729470 Status: Success (0x00) Handle: 21 Encryption: Enabled with E0 (0x01) > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 22.741045 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 25 (0x0019) Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.741104 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 10 [hci0] 22.741111 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Vendor (0xff) plen 4 [hci0] 22.741466 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.750463 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.751462 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.757325 L2CAP: Information Response (0x0b) ident 1 len 8 Type: Extended features supported (0x0002) Result: Success (0x0000) Features: 0x00000000 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.757384 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.757389 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.766471 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.767464 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.783656 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) MTU: 895 < ACL Data TX: Handle 21 flags 0x00 dlen 18 [hci0] 22.783723 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) MTU: 895 > ACL Data RX: Handle 21 flags 0x02 dlen 14 [hci0] 22.793532 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.795469 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 6 [hci0] 22.823472 Channel: 64 len 2 [PSM 25 mode 0] {chan 0} 10 01 .. < ACL Data TX: Handle 21 flags 0x00 dlen 8 [hci0] 22.823644 Channel: 65 len 4 [PSM 25 mode 0] {chan 0} 12 01 04 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.846535 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 22.868472 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 20 02 04 .. < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.868659 Channel: 65 len 12 [PSM 25 mode 0] {chan 0} 22 02 01 00 07 06 00 00 22 15 02 33 "......."..3 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.892465 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 18 [hci0] 22.934721 Channel: 64 len 14 [PSM 25 mode 0] {chan 0} 30 03 04 04 01 00 07 06 00 00 22 15 02 33 0........."..3 < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 22.934848 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 32 03 2. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.957466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 22.977206 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 40 06 04 @.. < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 22.977276 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 42 06 B. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.001471 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 23.031050 L2CAP: Connection Request (0x02) ident 4 len 4 PSM: 25 (0x0019) Source CID: 66 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 23.031137 L2CAP: Connection Response (0x03) ident 4 len 8 Destination CID: 65 Source CID: 66 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 23.031147 L2CAP: Configure Request (0x04) ident 3 len 4 Destination CID: 66 Flags: 0x0000 > HCI Event: Vendor (0xff) plen 4 [hci0] 23.031458 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.053469 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.055466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 23.079849 L2CAP: Configure Request (0x04) ident 5 len 8 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) MTU: 895 < ACL Data TX: Handle 21 flags 0x00 dlen 18 [hci0] 23.079898 L2CAP: Configure Response (0x05) ident 5 len 10 Source CID: 66 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) MTU: 895 > ACL Data RX: Handle 21 flags 0x02 dlen 14 [hci0] 23.089835 L2CAP: Configure Response (0x05) ident 3 len 6 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.091465 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Link Supervision Timeout Changed (0x38) plen 4 [hci0] 23.206472 Handle: 21 Timeout: 10080.000 msec (0x3f00) > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 23.219721 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 50 07 04 P.. < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 23.219831 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 52 07 R. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.233466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 23.282281 L2CAP: Connection Request (0x02) ident 6 len 4 PSM: 23 (0x0017) Source CID: 67 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 23.282363 L2CAP: Connection Response (0x03) ident 6 len 8 Destination CID: 0 Source CID: 67 Result: Connection refused - PSM not supported (0x0002) Status: No further information available (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.306540 Num handles: 1 Handle: 21 Count: 1 [-- Attachment #3: btmon_bluetoothd --] [-- Type: application/octet-stream, Size: 12380 bytes --] Bluetooth monitor ver 5.19 = New Index: 3C:77:E6:60:5C:B2 (BR/EDR,USB,hci0) [hci0] 0.564246 > HCI Event: Vendor (0xff) plen 2 [hci0] 21.526832 81 00 .. > HCI Event: Connect Request (0x04) plen 10 [hci0] 21.527763 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 [hci0] 21.527823 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Master (0x00) > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.528754 Accept Connection Request (0x01|0x0009) ncmd 1 Status: Success (0x00) > HCI Event: Role Change (0x12) plen 8 [hci0] 21.680833 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Master (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 21.752830 81 01 .. > HCI Event: Vendor (0xff) plen 7 [hci0] 21.753762 82 00 00 00 01 15 00 ....... > HCI Event: Connect Complete (0x03) plen 11 [hci0] 21.754761 Status: Success (0x00) Handle: 21 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 [hci0] 21.754922 Handle: 21 > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.755754 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Supported Features (0x0b) plen 11 [hci0] 21.791757 Status: Success (0x00) Handle: 21 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Extended features < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 [hci0] 21.791806 Handle: 21 Page: 1 > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.792750 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Extended Features (0x23) plen 13 [hci0] 21.801761 Status: Success (0x00) Handle: 21 Page: 1/1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) < HCI Command: Remote Name Request (0x01|0x0019) plen 10 [hci0] 21.801798 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 > HCI Event: Vendor (0xff) plen 2 [hci0] 21.802759 81 00 .. > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.803769 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 21.825755 81 01 .. > HCI Event: Remote Name Req Complete (0x07) plen 255 [hci0] 21.842744 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Name: Monster Clarity @ Device Connected: 10:B7:F6:01:31:ED (0) flags 0x0000 10 09 4d 6f 6e 73 74 65 72 20 43 6c 61 72 69 74 ..Monster Clarit 79 04 0d 04 04 24 y....$ > HCI Event: Link Key Request (0x17) plen 6 [hci0] 21.879776 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 [hci0] 21.879877 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link key: 9a1e116ffd4baad792d15c680b35f152 > HCI Event: Command Complete (0x0e) plen 10 [hci0] 21.882760 Link Key Request Reply (0x01|0x000b) ncmd 1 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) > HCI Event: Encryption Change (0x08) plen 4 [hci0] 21.996829 Status: Success (0x00) Handle: 21 Encryption: Enabled with E0 (0x01) > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 21.997576 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 25 (0x0019) Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 21.997644 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 10 [hci0] 21.997652 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Vendor (0xff) plen 4 [hci0] 21.997755 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.000760 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.001757 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.030118 L2CAP: Information Response (0x0b) ident 1 len 8 Type: Extended features supported (0x0002) Result: Success (0x0000) Features: 0x00000000 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030160 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030595 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.030735 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.032754 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.033752 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.035751 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 22.085097 L2CAP: Disconnection Request (0x06) ident 3 len 4 Destination CID: 64 Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.085139 L2CAP: Disconnection Response (0x07) ident 3 len 4 Destination CID: 64 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.087762 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Vendor (0xff) plen 7 [hci0] 22.354831 82 00 01 00 01 15 00 ....... > HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 22.355759 Status: Success (0x00) Handle: 21 Reason: Remote User Terminated Connection (0x13) @ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-18 7:11 ` Artem Rakhov 2014-08-20 22:52 ` Artem Rakhov @ 2014-08-20 22:54 ` Artem Rakhov 2014-08-21 6:42 ` Artem Rakhov 1 sibling, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-20 22:54 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 2537 bytes --] Hello, I found the way to use avtest for testing incoming connections from the speaker. If anyone is interested: stopped bluetoothd, powered BT back to on, used "avtest --reject 0". Also had to change avtest to answer like source instead of sink, which is set by default. Incoming connections to avtest are always successful. And logs are very similar (attached). I think the main difference is that the bluetoothd requires authorization, while avtest does not. Thanks, Artem On Mon, Aug 18, 2014 at 12:11 AM, Artem Rakhov <arakhov@chromium.org> wrote: > Hi Luiz, > > I have also tried kernel 3.14, it didn't help. > How can I use avinfo for test? Looks like it shows only basic > information for the device. And it works fine with the speaker. > I tried to use avtest: when I try to connect to the speaker, > everything seems to be working good. Is there any way to use it to > test incoming connections? > > Thanks, > Artem > > On Sun, Aug 10, 2014 at 12:32 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> Hi Artem, >> >> On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> wrote: >>> Hi Marcel, >>> >>> Please find Packet Logger's btsnoop log in the attachment. >>> >>> So far I have 2 observations: >>> 1. Mac does not require any authorization (most likely it's not the cause) >>> 2. I found another BT speaker which works properly. At first, I'm >>> seeing the same behavior: speaker initiates connection, BlueZ sends >>> Configure Request (with no MTU), then speaker disconnects. But after >>> that the device tries to initiate connection for the second time, and >>> this time it is successful: after BlueZ sends Configure Request with >>> no MTU, speaker answers with another Configure Request (with some >>> MTU), and connection is established normally. Is it possible, that >>> BlueZ is doing something wrong, but then this new speaker tries >>> something else, while the old one does not? >> >> I could not find anything l2cap related in this logs, but I notice >> there a LE scanning ongoing perhaps you have should try disabling it >> with Disconnect method for now. Anyway A2DP code is not really >> involved with L2CAP connection setup so we would have to look at the >> kernel changes but I quick check doesn't show anything and you said >> you have tried with 3.10 so Im afraid this is only reproducible with >> some specific device. >> >> Btw, if you want to really isolate the problem you can try to connect >> using avinfo or l2test directly. >> >> >> -- >> Luiz Augusto von Dentz [-- Attachment #2: btmon_avtest --] [-- Type: application/octet-stream, Size: 18928 bytes --] luetooth monitor ver 5.19 = New Index: 3C:77:E6:60:5C:B2 (BR/EDR,USB,hci0) [hci0] 0.456259 > HCI Event: Vendor (0xff) plen 2 [hci0] 22.527472 81 00 .. > HCI Event: Connect Request (0x04) plen 10 [hci0] 22.528472 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 [hci0] 22.528565 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Slave (0x01) > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.529462 Accept Connection Request (0x01|0x0009) ncmd 1 Status: Success (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 22.576536 81 01 .. > HCI Event: Vendor (0xff) plen 7 [hci0] 22.577469 82 00 00 01 01 15 00 ....... > HCI Event: Connect Complete (0x03) plen 11 [hci0] 22.578469 Status: Success (0x00) Handle: 21 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 [hci0] 22.578641 Handle: 21 > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.579463 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Supported Features (0x0b) plen 11 [hci0] 22.605538 Status: Success (0x00) Handle: 21 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Extended features < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 [hci0] 22.605584 Handle: 21 Page: 1 > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.606460 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Extended Features (0x23) plen 13 [hci0] 22.615477 Status: Success (0x00) Handle: 21 Page: 1/1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) < HCI Command: Remote Name Request (0x01|0x0019) plen 10 [hci0] 22.615583 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 > HCI Event: Vendor (0xff) plen 2 [hci0] 22.616462 81 00 .. > HCI Event: Command Status (0x0f) plen 4 [hci0] 22.617463 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Link Key Request (0x17) plen 6 [hci0] 22.654535 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 [hci0] 22.654580 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link key: 9a1e116ffd4baad792d15c680b35f152 > HCI Event: Command Complete (0x0e) plen 10 [hci0] 22.657473 Link Key Request Reply (0x01|0x000b) ncmd 1 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) > HCI Event: Vendor (0xff) plen 2 [hci0] 22.659466 81 01 .. > HCI Event: Remote Name Req Complete (0x07) plen 255 [hci0] 22.676479 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Name: Monster Clarity @ Device Connected: 10:B7:F6:01:31:ED (0) flags 0x0000 10 09 4d 6f 6e 73 74 65 72 20 43 6c 61 72 69 74 ..Monster Clarit 79 04 0d 04 04 24 y....$ > HCI Event: Encryption Change (0x08) plen 4 [hci0] 22.729470 Status: Success (0x00) Handle: 21 Encryption: Enabled with E0 (0x01) > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 22.741045 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 25 (0x0019) Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.741104 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 10 [hci0] 22.741111 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Vendor (0xff) plen 4 [hci0] 22.741466 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.750463 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.751462 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.757325 L2CAP: Information Response (0x0b) ident 1 len 8 Type: Extended features supported (0x0002) Result: Success (0x0000) Features: 0x00000000 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.757384 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.757389 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.766471 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.767464 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.783656 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 64 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) MTU: 895 < ACL Data TX: Handle 21 flags 0x00 dlen 18 [hci0] 22.783723 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) MTU: 895 > ACL Data RX: Handle 21 flags 0x02 dlen 14 [hci0] 22.793532 L2CAP: Configure Response (0x05) ident 2 len 6 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.795469 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 6 [hci0] 22.823472 Channel: 64 len 2 [PSM 25 mode 0] {chan 0} 10 01 .. < ACL Data TX: Handle 21 flags 0x00 dlen 8 [hci0] 22.823644 Channel: 65 len 4 [PSM 25 mode 0] {chan 0} 12 01 04 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.846535 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 22.868472 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 20 02 04 .. < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.868659 Channel: 65 len 12 [PSM 25 mode 0] {chan 0} 22 02 01 00 07 06 00 00 22 15 02 33 "......."..3 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.892465 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 18 [hci0] 22.934721 Channel: 64 len 14 [PSM 25 mode 0] {chan 0} 30 03 04 04 01 00 07 06 00 00 22 15 02 33 0........."..3 < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 22.934848 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 32 03 2. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.957466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 22.977206 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 40 06 04 @.. < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 22.977276 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 42 06 B. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.001471 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 23.031050 L2CAP: Connection Request (0x02) ident 4 len 4 PSM: 25 (0x0019) Source CID: 66 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 23.031137 L2CAP: Connection Response (0x03) ident 4 len 8 Destination CID: 65 Source CID: 66 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 23.031147 L2CAP: Configure Request (0x04) ident 3 len 4 Destination CID: 66 Flags: 0x0000 > HCI Event: Vendor (0xff) plen 4 [hci0] 23.031458 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.053469 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.055466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 23.079849 L2CAP: Configure Request (0x04) ident 5 len 8 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) MTU: 895 < ACL Data TX: Handle 21 flags 0x00 dlen 18 [hci0] 23.079898 L2CAP: Configure Response (0x05) ident 5 len 10 Source CID: 66 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) MTU: 895 > ACL Data RX: Handle 21 flags 0x02 dlen 14 [hci0] 23.089835 L2CAP: Configure Response (0x05) ident 3 len 6 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.091465 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Link Supervision Timeout Changed (0x38) plen 4 [hci0] 23.206472 Handle: 21 Timeout: 10080.000 msec (0x3f00) > ACL Data RX: Handle 21 flags 0x02 dlen 7 [hci0] 23.219721 Channel: 64 len 3 [PSM 25 mode 0] {chan 0} 50 07 04 P.. < ACL Data TX: Handle 21 flags 0x00 dlen 6 [hci0] 23.219831 Channel: 65 len 2 [PSM 25 mode 0] {chan 0} 52 07 R. > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.233466 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 23.282281 L2CAP: Connection Request (0x02) ident 6 len 4 PSM: 23 (0x0017) Source CID: 67 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 23.282363 L2CAP: Connection Response (0x03) ident 6 len 8 Destination CID: 0 Source CID: 67 Result: Connection refused - PSM not supported (0x0002) Status: No further information available (0x0000) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 23.306540 Num handles: 1 Handle: 21 Count: 1 [-- Attachment #3: btmon_bluetoothd --] [-- Type: application/octet-stream, Size: 12380 bytes --] Bluetooth monitor ver 5.19 = New Index: 3C:77:E6:60:5C:B2 (BR/EDR,USB,hci0) [hci0] 0.564246 > HCI Event: Vendor (0xff) plen 2 [hci0] 21.526832 81 00 .. > HCI Event: Connect Request (0x04) plen 10 [hci0] 21.527763 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Class: 0x240404 Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device Rendering (Printing, Speaker) Audio (Speaker, Microphone, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 [hci0] 21.527823 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Master (0x00) > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.528754 Accept Connection Request (0x01|0x0009) ncmd 1 Status: Success (0x00) > HCI Event: Role Change (0x12) plen 8 [hci0] 21.680833 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Role: Master (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 21.752830 81 01 .. > HCI Event: Vendor (0xff) plen 7 [hci0] 21.753762 82 00 00 00 01 15 00 ....... > HCI Event: Connect Complete (0x03) plen 11 [hci0] 21.754761 Status: Success (0x00) Handle: 21 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 [hci0] 21.754922 Handle: 21 > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.755754 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Supported Features (0x0b) plen 11 [hci0] 21.791757 Status: Success (0x00) Handle: 21 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Extended features < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 [hci0] 21.791806 Handle: 21 Page: 1 > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.792750 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Extended Features (0x23) plen 13 [hci0] 21.801761 Status: Success (0x00) Handle: 21 Page: 1/1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) < HCI Command: Remote Name Request (0x01|0x0019) plen 10 [hci0] 21.801798 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 > HCI Event: Vendor (0xff) plen 2 [hci0] 21.802759 81 00 .. > HCI Event: Command Status (0x0f) plen 4 [hci0] 21.803769 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Vendor (0xff) plen 2 [hci0] 21.825755 81 01 .. > HCI Event: Remote Name Req Complete (0x07) plen 255 [hci0] 21.842744 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Name: Monster Clarity @ Device Connected: 10:B7:F6:01:31:ED (0) flags 0x0000 10 09 4d 6f 6e 73 74 65 72 20 43 6c 61 72 69 74 ..Monster Clarit 79 04 0d 04 04 24 y....$ > HCI Event: Link Key Request (0x17) plen 6 [hci0] 21.879776 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 [hci0] 21.879877 Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) Link key: 9a1e116ffd4baad792d15c680b35f152 > HCI Event: Command Complete (0x0e) plen 10 [hci0] 21.882760 Link Key Request Reply (0x01|0x000b) ncmd 1 Status: Success (0x00) Address: 10:B7:F6:01:31:ED (OUI 10-B7-F6) > HCI Event: Encryption Change (0x08) plen 4 [hci0] 21.996829 Status: Success (0x00) Handle: 21 Encryption: Enabled with E0 (0x01) > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 21.997576 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 25 (0x0019) Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 21.997644 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 10 [hci0] 21.997652 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Vendor (0xff) plen 4 [hci0] 21.997755 86 03 15 00 .... > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.000760 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.001757 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 16 [hci0] 22.030118 L2CAP: Information Response (0x0b) ident 1 len 8 Type: Extended features supported (0x0002) Result: Success (0x0000) Features: 0x00000000 < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030160 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030595 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.030735 L2CAP: Configure Request (0x04) ident 2 len 4 Destination CID: 65 Flags: 0x0000 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.032754 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.033752 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.035751 Num handles: 1 Handle: 21 Count: 1 > ACL Data RX: Handle 21 flags 0x02 dlen 12 [hci0] 22.085097 L2CAP: Disconnection Request (0x06) ident 3 len 4 Destination CID: 64 Source CID: 65 < ACL Data TX: Handle 21 flags 0x00 dlen 12 [hci0] 22.085139 L2CAP: Disconnection Response (0x07) ident 3 len 4 Destination CID: 64 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 22.087762 Num handles: 1 Handle: 21 Count: 1 > HCI Event: Vendor (0xff) plen 7 [hci0] 22.354831 82 00 01 00 01 15 00 ....... > HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 22.355759 Status: Success (0x00) Handle: 21 Reason: Remote User Terminated Connection (0x13) @ Device Disconnected: 10:B7:F6:01:31:ED (0) reason 3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-20 22:54 ` Artem Rakhov @ 2014-08-21 6:42 ` Artem Rakhov 2014-08-21 8:38 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-21 6:42 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth, gustavo Looks like I found the problem. Creation of all sockets and all the read/write operations are handled in btio.c in BlueZ. It allows to set various options for sockets. One of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By default it is equal to 30. In fact, no profile in BlueZ use this option, and it is never equal to anything else. And create_io() function in btio.c also does not use this. The only place 'defer' option is passed to a kernel level is bt_io_listen() function: if (confirm) setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, sizeof(opts.defer)); As far as I understand, BT_DEFER_SETUP is a kernel option which enables Defer Setup feature for L2CAP channel. It is a binary flag, and looks like it has nothing to do with timeout. And it makes no sense to pass 30 as a value for binary flag. So I don't see any connection between these two things. As a result, we almost always turn on Defer Setup feature, which causes connection problems with my speaker and potentially with other BT devices. My suggestion is to completely remove 'defer' option from btio.c Another question is: when and where do we actually need to enable this Defer Setup feature? Thanks, Artem On Wed, Aug 20, 2014 at 3:54 PM, Artem Rakhov <arakhov@google.com> wrote: > Hello, > > I found the way to use avtest for testing incoming connections from > the speaker. If anyone is interested: stopped bluetoothd, powered BT > back to on, used "avtest --reject 0". Also had to change avtest to > answer like source instead of sink, which is set by default. > > Incoming connections to avtest are always successful. And logs are > very similar (attached). I think the main difference is that the > bluetoothd requires authorization, while avtest does not. > > Thanks, > Artem > > On Mon, Aug 18, 2014 at 12:11 AM, Artem Rakhov <arakhov@chromium.org> wrote: >> Hi Luiz, >> >> I have also tried kernel 3.14, it didn't help. >> How can I use avinfo for test? Looks like it shows only basic >> information for the device. And it works fine with the speaker. >> I tried to use avtest: when I try to connect to the speaker, >> everything seems to be working good. Is there any way to use it to >> test incoming connections? >> >> Thanks, >> Artem >> >> On Sun, Aug 10, 2014 at 12:32 AM, Luiz Augusto von Dentz >> <luiz.dentz@gmail.com> wrote: >>> Hi Artem, >>> >>> On Fri, Aug 8, 2014 at 10:32 AM, Artem Rakhov <arakhov@chromium.org> wrote: >>>> Hi Marcel, >>>> >>>> Please find Packet Logger's btsnoop log in the attachment. >>>> >>>> So far I have 2 observations: >>>> 1. Mac does not require any authorization (most likely it's not the cause) >>>> 2. I found another BT speaker which works properly. At first, I'm >>>> seeing the same behavior: speaker initiates connection, BlueZ sends >>>> Configure Request (with no MTU), then speaker disconnects. But after >>>> that the device tries to initiate connection for the second time, and >>>> this time it is successful: after BlueZ sends Configure Request with >>>> no MTU, speaker answers with another Configure Request (with some >>>> MTU), and connection is established normally. Is it possible, that >>>> BlueZ is doing something wrong, but then this new speaker tries >>>> something else, while the old one does not? >>> >>> I could not find anything l2cap related in this logs, but I notice >>> there a LE scanning ongoing perhaps you have should try disabling it >>> with Disconnect method for now. Anyway A2DP code is not really >>> involved with L2CAP connection setup so we would have to look at the >>> kernel changes but I quick check doesn't show anything and you said >>> you have tried with 3.10 so Im afraid this is only reproducible with >>> some specific device. >>> >>> Btw, if you want to really isolate the problem you can try to connect >>> using avinfo or l2test directly. >>> >>> >>> -- >>> Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 6:42 ` Artem Rakhov @ 2014-08-21 8:38 ` Luiz Augusto von Dentz 2014-08-21 13:33 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-08-21 8:38 UTC (permalink / raw) To: Artem Rakhov; +Cc: Marcel Holtmann, linux-bluetooth, Gustavo F. Padovan Hi Artem, On Thu, Aug 21, 2014 at 9:42 AM, Artem Rakhov <arakhov@chromium.org> wrote: > Looks like I found the problem. > > Creation of all sockets and all the read/write operations are handled > in btio.c in BlueZ. It allows to set various options for sockets. One > of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By > default it is equal to 30. In fact, no profile in BlueZ use this > option, and it is never equal to anything else. And create_io() > function in btio.c also does not use this. The only place 'defer' > option is passed to a kernel level is bt_io_listen() function: > > if (confirm) > setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, > sizeof(opts.defer)); Yep the use of this API is wrong, we either set or reset the flag but there is no timeout involved, but this alone would not cause the problem since the kernel ignore the actual value and just set the flag properly: if (opt) { set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); set_bit(FLAG_DEFER_SETUP, &chan->flags); } > As far as I understand, BT_DEFER_SETUP is a kernel option which > enables Defer Setup feature for L2CAP channel. It is a binary flag, > and looks like it has nothing to do with timeout. And it makes no > sense to pass 30 as a value for binary flag. > > So I don't see any connection between these two things. As a result, > we almost always turn on Defer Setup feature, which causes connection > problems with my speaker and potentially with other BT devices. My > suggestion is to completely remove 'defer' option from btio.c > > Another question is: when and where do we actually need to enable this > Defer Setup feature? Defer Setup is quite fundamental to be able to authorize connection properly otherwise we would have to accept the connection upfront to be able to identify who is connecting, L2CAP has the authorization pending as response for this very reason and apparently your headset cannot handle it properly: < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030160 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) But note that bluetoothd accepts the connection almost immediately in the next frame (probably because the device is trusted): < ACL Data TX: Handle 21 flags 0x00 dlen 16 [hci0] 22.030595 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) This is part of the core specification, unfortunately it doesn't seems that any test of the testing specification do actually test it, so chances are that the headset could qualify just because PTS never send authorization/connection pending status. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 8:38 ` Luiz Augusto von Dentz @ 2014-08-21 13:33 ` Marcel Holtmann 2014-08-21 13:53 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 25+ messages in thread From: Marcel Holtmann @ 2014-08-21 13:33 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Artem Rakhov, linux-bluetooth, Gustavo F. Padovan Hi Luiz, >> Looks like I found the problem. >> >> Creation of all sockets and all the read/write operations are handled >> in btio.c in BlueZ. It allows to set various options for sockets. One >> of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By >> default it is equal to 30. In fact, no profile in BlueZ use this >> option, and it is never equal to anything else. And create_io() >> function in btio.c also does not use this. The only place 'defer' >> option is passed to a kernel level is bt_io_listen() function: >> >> if (confirm) >> setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, >> sizeof(opts.defer)); > > Yep the use of this API is wrong, we either set or reset the flag but > there is no timeout involved, but this alone would not cause the > problem since the kernel ignore the actual value and just set the flag > properly: > > if (opt) { > set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); > set_bit(FLAG_DEFER_SETUP, &chan->flags); > } > >> As far as I understand, BT_DEFER_SETUP is a kernel option which >> enables Defer Setup feature for L2CAP channel. It is a binary flag, >> and looks like it has nothing to do with timeout. And it makes no >> sense to pass 30 as a value for binary flag. >> >> So I don't see any connection between these two things. As a result, >> we almost always turn on Defer Setup feature, which causes connection >> problems with my speaker and potentially with other BT devices. My >> suggestion is to completely remove 'defer' option from btio.c >> >> Another question is: when and where do we actually need to enable this >> Defer Setup feature? > > Defer Setup is quite fundamental to be able to authorize connection > properly otherwise we would have to accept the connection upfront to > be able to identify who is connecting, L2CAP has the authorization > pending as response for this very reason and apparently your headset > cannot handle it properly: > > < ACL Data TX: Handle 21 flags 0x00 dlen 16 > [hci0] > 22.030160 > L2CAP: Connection Response (0x03) ident 2 len 8 > Destination CID: 64 > Source CID: 65 > Result: Connection pending (0x0001) > Status: Authorization pending (0x0002) > > > But note that bluetoothd accepts the connection almost immediately in > the next frame (probably because the device is trusted): > > < ACL Data TX: Handle 21 flags 0x00 dlen 16 > [hci0] > 22.030595 > L2CAP: Connection Response (0x03) ident 2 len 8 > Destination CID: 64 > Source CID: 65 > Result: Connection successful (0x0000) > Status: No further information available (0x0000) > > This is part of the core specification, unfortunately it doesn't seems > that any test of the testing specification do actually test it, so > chances are that the headset could qualify just because PTS never send > authorization/connection pending status. it is basic L2CAP behavior since Bluetooth 1.0b specification. It always worked like this. And many many devices are using it exactly like this. It gets ever funnier when the Bluetooth stack puts the Connection Pending and Connection Successful into the same ACL frame. Is the conclusion that the headset can not handle L2CAP Connection Pending status? Just for my entertainment, can you run hcitool info against that headset and see what manufacturer it is. I am really curious on who got this wrong. Which model is this exactly? Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 13:33 ` Marcel Holtmann @ 2014-08-21 13:53 ` Luiz Augusto von Dentz 2014-08-21 14:28 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-08-21 13:53 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Artem Rakhov, linux-bluetooth, Gustavo F. Padovan Hi Marcel, On Thu, Aug 21, 2014 at 4:33 PM, Marcel Holtmann <marcel@holtmann.org> wrot= e: > Hi Luiz, > >>> Looks like I found the problem. >>> >>> Creation of all sockets and all the read/write operations are handled >>> in btio.c in BlueZ. It allows to set various options for sockets. One >>> of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By >>> default it is equal to 30. In fact, no profile in BlueZ use this >>> option, and it is never equal to anything else. And create_io() >>> function in btio.c also does not use this. The only place 'defer' >>> option is passed to a kernel level is bt_io_listen() function: >>> >>> if (confirm) >>> setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, >>> sizeof(opts.defer)); >> >> Yep the use of this API is wrong, we either set or reset the flag but >> there is no timeout involved, but this alone would not cause the >> problem since the kernel ignore the actual value and just set the flag >> properly: >> >> if (opt) { >> set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); >> set_bit(FLAG_DEFER_SETUP, &chan->flags); >> } >> >>> As far as I understand, BT_DEFER_SETUP is a kernel option which >>> enables Defer Setup feature for L2CAP channel. It is a binary flag, >>> and looks like it has nothing to do with timeout. And it makes no >>> sense to pass 30 as a value for binary flag. >>> >>> So I don't see any connection between these two things. As a result, >>> we almost always turn on Defer Setup feature, which causes connection >>> problems with my speaker and potentially with other BT devices. My >>> suggestion is to completely remove 'defer' option from btio.c >>> >>> Another question is: when and where do we actually need to enable this >>> Defer Setup feature? >> >> Defer Setup is quite fundamental to be able to authorize connection >> properly otherwise we would have to accept the connection upfront to >> be able to identify who is connecting, L2CAP has the authorization >> pending as response for this very reason and apparently your headset >> cannot handle it properly: >> >> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >> [hci0] >> 22.030160 >> L2CAP: Connection Response (0x03) ident 2 len 8 >> Destination CID: 64 >> Source CID: 65 >> Result: Connection pending (0x0001) >> Status: Authorization pending (0x0002) >> >> >> But note that bluetoothd accepts the connection almost immediately in >> the next frame (probably because the device is trusted): >> >> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >> [hci0] >> 22.030595 >> L2CAP: Connection Response (0x03) ident 2 len 8 >> Destination CID: 64 >> Source CID: 65 >> Result: Connection successful (0x0000) >> Status: No further information available (0x0000) >> >> This is part of the core specification, unfortunately it doesn't seems >> that any test of the testing specification do actually test it, so >> chances are that the headset could qualify just because PTS never send >> authorization/connection pending status. > > it is basic L2CAP behavior since Bluetooth 1.0b specification. It always = worked like this. And many many devices are using it exactly like this. It = gets ever funnier when the Bluetooth stack puts the Connection Pending and = Connection Successful into the same ACL frame. I suspected it is a very basic since iirc we introduce Defer Setup long time ago and never run into this specific problem. Now if that actually gets in the same ACL frame this could cause a stack to ignore the subsequent response which perhaps is the problem here. > Is the conclusion that the headset can not handle L2CAP Connection Pendin= g status? Just for my entertainment, can you run hcitool info against that = headset and see what manufacturer it is. I am really curious on who got thi= s wrong. Which model is this exactly? No idea, perhaps Artem is willing to disclose the model, from the logs it seems it hangs if authorization pending is sent and then at some point it probably timeout and disconnects. We do have some logic to handle devices that connect but do not configure any stream, perhaps we could fit this in the same category and if they disconnect while authorizing we attempt to reconnect, it is probably to much of a hack but if the device is really popular then perhaps it is worth trying. --=20 Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 13:53 ` Luiz Augusto von Dentz @ 2014-08-21 14:28 ` Marcel Holtmann 2014-08-21 19:16 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Marcel Holtmann @ 2014-08-21 14:28 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Artem Rakhov, linux-bluetooth, Gustavo F. Padovan Hi Luiz, >>>> Looks like I found the problem. >>>> >>>> Creation of all sockets and all the read/write operations are handled >>>> in btio.c in BlueZ. It allows to set various options for sockets. One >>>> of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By >>>> default it is equal to 30. In fact, no profile in BlueZ use this >>>> option, and it is never equal to anything else. And create_io() >>>> function in btio.c also does not use this. The only place 'defer' >>>> option is passed to a kernel level is bt_io_listen() function: >>>> >>>> if (confirm) >>>> setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, >>>> sizeof(opts.defer)); >>> >>> Yep the use of this API is wrong, we either set or reset the flag but >>> there is no timeout involved, but this alone would not cause the >>> problem since the kernel ignore the actual value and just set the flag >>> properly: >>> >>> if (opt) { >>> set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); >>> set_bit(FLAG_DEFER_SETUP, &chan->flags); >>> } >>> >>>> As far as I understand, BT_DEFER_SETUP is a kernel option which >>>> enables Defer Setup feature for L2CAP channel. It is a binary flag, >>>> and looks like it has nothing to do with timeout. And it makes no >>>> sense to pass 30 as a value for binary flag. >>>> >>>> So I don't see any connection between these two things. As a result, >>>> we almost always turn on Defer Setup feature, which causes connection >>>> problems with my speaker and potentially with other BT devices. My >>>> suggestion is to completely remove 'defer' option from btio.c >>>> >>>> Another question is: when and where do we actually need to enable this >>>> Defer Setup feature? >>> >>> Defer Setup is quite fundamental to be able to authorize connection >>> properly otherwise we would have to accept the connection upfront to >>> be able to identify who is connecting, L2CAP has the authorization >>> pending as response for this very reason and apparently your headset >>> cannot handle it properly: >>> >>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>> [hci0] >>> 22.030160 >>> L2CAP: Connection Response (0x03) ident 2 len 8 >>> Destination CID: 64 >>> Source CID: 65 >>> Result: Connection pending (0x0001) >>> Status: Authorization pending (0x0002) >>> >>> >>> But note that bluetoothd accepts the connection almost immediately in >>> the next frame (probably because the device is trusted): >>> >>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>> [hci0] >>> 22.030595 >>> L2CAP: Connection Response (0x03) ident 2 len 8 >>> Destination CID: 64 >>> Source CID: 65 >>> Result: Connection successful (0x0000) >>> Status: No further information available (0x0000) >>> >>> This is part of the core specification, unfortunately it doesn't seems >>> that any test of the testing specification do actually test it, so >>> chances are that the headset could qualify just because PTS never send >>> authorization/connection pending status. >> >> it is basic L2CAP behavior since Bluetooth 1.0b specification. It always worked like this. And many many devices are using it exactly like this. It gets ever funnier when the Bluetooth stack puts the Connection Pending and Connection Successful into the same ACL frame. > > I suspected it is a very basic since iirc we introduce Defer Setup > long time ago and never run into this specific problem. Now if that > actually gets in the same ACL frame this could cause a stack to ignore > the subsequent response which perhaps is the problem here. I don't think so since there is a test case for this. Question is just if the remote device can really handle the Connection Pending correctly. >> Is the conclusion that the headset can not handle L2CAP Connection Pending status? Just for my entertainment, can you run hcitool info against that headset and see what manufacturer it is. I am really curious on who got this wrong. Which model is this exactly? > > No idea, perhaps Artem is willing to disclose the model, from the logs > it seems it hangs if authorization pending is sent and then at some > point it probably timeout and disconnects. > > We do have some logic to handle devices that connect but do not > configure any stream, perhaps we could fit this in the same category > and if they disconnect while authorizing we attempt to reconnect, it > is probably to much of a hack but if the device is really popular then > perhaps it is worth trying. That is something that could work. Since I rather not change the kernel logic to handle and accept() plus a read() right after it with a special delay turning this into a Connection Succesful. It might be also worthwhile to check if there is a firmware update for this speaker available. I can imagine that this causes issues for a few stacks. Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 14:28 ` Marcel Holtmann @ 2014-08-21 19:16 ` Artem Rakhov 2014-08-21 20:24 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-21 19:16 UTC (permalink / raw) To: Marcel Holtmann Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan Here is hcitool info: BD Address: 10:B7:F6:01:31:ED Device Name: Monster Clarity LMP Version: 2.1 (0x4) LMP Subversion: 0x189c Manufacturer: Cambridge Silicon Radio (10) Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 <3-slot packets> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 Label also says Precision Micro Bluetooth Speaker 100. Thanks, Artem On Thu, Aug 21, 2014 at 7:28 AM, Marcel Holtmann <marcel@holtmann.org> wrot= e: > Hi Luiz, > >>>>> Looks like I found the problem. >>>>> >>>>> Creation of all sockets and all the read/write operations are handled >>>>> in btio.c in BlueZ. It allows to set various options for sockets. One >>>>> of these options is called 'defer' (BT_IO_OPT_DEFER_TIMEOUT). By >>>>> default it is equal to 30. In fact, no profile in BlueZ use this >>>>> option, and it is never equal to anything else. And create_io() >>>>> function in btio.c also does not use this. The only place 'defer' >>>>> option is passed to a kernel level is bt_io_listen() function: >>>>> >>>>> if (confirm) >>>>> setsockopt(sock, SOL_BLUETOOTH, BT_DEFER_SETUP, &opts.defer, >>>>> sizeof(opts.defer)); >>>> >>>> Yep the use of this API is wrong, we either set or reset the flag but >>>> there is no timeout involved, but this alone would not cause the >>>> problem since the kernel ignore the actual value and just set the flag >>>> properly: >>>> >>>> if (opt) { >>>> set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); >>>> set_bit(FLAG_DEFER_SETUP, &chan->flags); >>>> } >>>> >>>>> As far as I understand, BT_DEFER_SETUP is a kernel option which >>>>> enables Defer Setup feature for L2CAP channel. It is a binary flag, >>>>> and looks like it has nothing to do with timeout. And it makes no >>>>> sense to pass 30 as a value for binary flag. >>>>> >>>>> So I don't see any connection between these two things. As a result, >>>>> we almost always turn on Defer Setup feature, which causes connection >>>>> problems with my speaker and potentially with other BT devices. My >>>>> suggestion is to completely remove 'defer' option from btio.c >>>>> >>>>> Another question is: when and where do we actually need to enable thi= s >>>>> Defer Setup feature? >>>> >>>> Defer Setup is quite fundamental to be able to authorize connection >>>> properly otherwise we would have to accept the connection upfront to >>>> be able to identify who is connecting, L2CAP has the authorization >>>> pending as response for this very reason and apparently your headset >>>> cannot handle it properly: >>>> >>>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>>> [hci0] >>>> 22.030160 >>>> L2CAP: Connection Response (0x03) ident 2 len 8 >>>> Destination CID: 64 >>>> Source CID: 65 >>>> Result: Connection pending (0x0001) >>>> Status: Authorization pending (0x0002) >>>> >>>> >>>> But note that bluetoothd accepts the connection almost immediately in >>>> the next frame (probably because the device is trusted): >>>> >>>> < ACL Data TX: Handle 21 flags 0x00 dlen 16 >>>> [hci0] >>>> 22.030595 >>>> L2CAP: Connection Response (0x03) ident 2 len 8 >>>> Destination CID: 64 >>>> Source CID: 65 >>>> Result: Connection successful (0x0000) >>>> Status: No further information available (0x0000) >>>> >>>> This is part of the core specification, unfortunately it doesn't seems >>>> that any test of the testing specification do actually test it, so >>>> chances are that the headset could qualify just because PTS never send >>>> authorization/connection pending status. >>> >>> it is basic L2CAP behavior since Bluetooth 1.0b specification. It alway= s worked like this. And many many devices are using it exactly like this. I= t gets ever funnier when the Bluetooth stack puts the Connection Pending an= d Connection Successful into the same ACL frame. >> >> I suspected it is a very basic since iirc we introduce Defer Setup >> long time ago and never run into this specific problem. Now if that >> actually gets in the same ACL frame this could cause a stack to ignore >> the subsequent response which perhaps is the problem here. > > I don't think so since there is a test case for this. Question is just if= the remote device can really handle the Connection Pending correctly. > >>> Is the conclusion that the headset can not handle L2CAP Connection Pend= ing status? Just for my entertainment, can you run hcitool info against tha= t headset and see what manufacturer it is. I am really curious on who got t= his wrong. Which model is this exactly? >> >> No idea, perhaps Artem is willing to disclose the model, from the logs >> it seems it hangs if authorization pending is sent and then at some >> point it probably timeout and disconnects. >> >> We do have some logic to handle devices that connect but do not >> configure any stream, perhaps we could fit this in the same category >> and if they disconnect while authorizing we attempt to reconnect, it >> is probably to much of a hack but if the device is really popular then >> perhaps it is worth trying. > > That is something that could work. Since I rather not change the kernel l= ogic to handle and accept() plus a read() right after it with a special del= ay turning this into a Connection Succesful. > > It might be also worthwhile to check if there is a firmware update for th= is speaker available. I can imagine that this causes issues for a few stack= s. > > Regards > > Marcel > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 19:16 ` Artem Rakhov @ 2014-08-21 20:24 ` Marcel Holtmann 2014-08-21 21:31 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Marcel Holtmann @ 2014-08-21 20:24 UTC (permalink / raw) To: Artem Rakhov; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan Hi Artem, please do not top post on this mailing list. It does break the reading thread. > Here is hcitool info: > > BD Address: 10:B7:F6:01:31:ED > Device Name: Monster Clarity > LMP Version: 2.1 (0x4) LMP Subversion: 0x189c > Manufacturer: Cambridge Silicon Radio (10) > Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > <3-slot packets> > Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 > > Label also says Precision Micro Bluetooth Speaker 100. normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker. Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 20:24 ` Marcel Holtmann @ 2014-08-21 21:31 ` Artem Rakhov 2014-08-27 1:11 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-21 21:31 UTC (permalink / raw) To: Marcel Holtmann Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan > Hi Artem, > > please do not top post on this mailing list. It does break the reading thread. > >> Here is hcitool info: >> >> BD Address: 10:B7:F6:01:31:ED >> Device Name: Monster Clarity >> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >> Manufacturer: Cambridge Silicon Radio (10) >> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >> <3-slot packets> >> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >> >> Label also says Precision Micro Bluetooth Speaker 100. > > normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker. > > Regards > > Marcel > I compared the logs from avtest and bluetoothd (attached earlier in this thread). I think the only difference that could matter is this Authorization Pending response. Thanks, Artem ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-21 21:31 ` Artem Rakhov @ 2014-08-27 1:11 ` Artem Rakhov 2014-08-27 2:08 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-27 1:11 UTC (permalink / raw) To: Marcel Holtmann Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan On Thu, Aug 21, 2014 at 2:31 PM, Artem Rakhov <arakhov@chromium.org> wrote: >> Hi Artem, >> >> please do not top post on this mailing list. It does break the reading thread. >> >>> Here is hcitool info: >>> >>> BD Address: 10:B7:F6:01:31:ED >>> Device Name: Monster Clarity >>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>> Manufacturer: Cambridge Silicon Radio (10) >>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>> <3-slot packets> >>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>> >>> Label also says Precision Micro Bluetooth Speaker 100. >> >> normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker. >> >> Regards >> >> Marcel >> > > I compared the logs from avtest and bluetoothd (attached earlier in > this thread). I think the only difference that could matter is this > Authorization Pending response. > > Thanks, > Artem Hi Marcel, I've tested several devices with and without Defer Setup feature enabled. Here is a list of devices, which successfully initiate A2DP connection, not depending on Defer Setup: Creative WP-350 Headset MiiKey Rythm JBL Micro Wireless HMDX Rave Plantronics BBfit Bose SoundLink Mobile speaker II SOL Tracks Air Sony MDR-1RBT Here is a list of devices, which fail to initiate A2DP connection with Defer Setup enabled, but work fine when Defer Setup is disabled: Monster Clarity HD Motorola S9-HD Sennheiser PX210 2010 Toyota Prius There are no devices, which are working with Defer Setup, and not working without Defer Setup. So I didn't see any regression. As a result, 4 out of 12 devices do not connect as expected with Defer Setup enabled. I think we should consider disabling Defer Setup by default, at least for audio. Thanks, Artem ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-27 1:11 ` Artem Rakhov @ 2014-08-27 2:08 ` Marcel Holtmann 2014-08-27 6:33 ` Artem Rakhov 0 siblings, 1 reply; 25+ messages in thread From: Marcel Holtmann @ 2014-08-27 2:08 UTC (permalink / raw) To: Artem Rakhov; +Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan Hi Artem, >>> please do not top post on this mailing list. It does break the reading thread. >>> >>>> Here is hcitool info: >>>> >>>> BD Address: 10:B7:F6:01:31:ED >>>> Device Name: Monster Clarity >>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>>> Manufacturer: Cambridge Silicon Radio (10) >>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> <3-slot packets> >>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>>> >>>> Label also says Precision Micro Bluetooth Speaker 100. >>> >>> normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker. >> >> I compared the logs from avtest and bluetoothd (attached earlier in >> this thread). I think the only difference that could matter is this >> Authorization Pending response. > > I've tested several devices with and without Defer Setup feature enabled. > > Here is a list of devices, which successfully initiate A2DP > connection, not depending on Defer Setup: > Creative WP-350 Headset > MiiKey Rythm > JBL Micro Wireless > HMDX Rave > Plantronics BBfit > Bose SoundLink Mobile speaker II > SOL Tracks Air > Sony MDR-1RBT > > Here is a list of devices, which fail to initiate A2DP connection with > Defer Setup enabled, but work fine when Defer Setup is disabled: > Monster Clarity HD > Motorola S9-HD > Sennheiser PX210 > 2010 Toyota Prius are all of these CSR based devices? If so then it sounds like a batch of broken CSR firmware. If not, then the L2CAP test cases might better be extended to have a test case for this. It is dangerous if such a fundamental Bluetooth 1.1 feature is not working correctly. > There are no devices, which are working with Defer Setup, and not > working without Defer Setup. So I didn't see any regression. > > As a result, 4 out of 12 devices do not connect as expected with Defer > Setup enabled. I think we should consider disabling Defer Setup by > default, at least for audio. I all cases this is the A2DP signaling channel that causes the problem? It is not the media channel that is required for streaming? Our real problem is that we need Defer Setup to be able to cleanly reject connections from devices that we do not know and do not want to talk to use. Especially if they are just not authorized to do so. Maybe we should use the proposal that Luiz had and just disconnect after a timeout and try to establish the connection from our side. That might actually be useful as a workaround. An alternative option is that we delay the connection pending message for some time and give userspace the chance to respond with either read() or close(). That way we would send the correct answer. However that timeout can only be really short since we need to keep the L2CAP signaling working correctly. So it would only work for cases where the daemon has all information to make a decision. If it asks the user, then this is off limits. That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that might be useful to mitigate this behavior as well. Unknown devices would be blocked on the ACL level already. Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-27 2:08 ` Marcel Holtmann @ 2014-08-27 6:33 ` Artem Rakhov 2014-08-27 18:34 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 25+ messages in thread From: Artem Rakhov @ 2014-08-27 6:33 UTC (permalink / raw) To: Marcel Holtmann Cc: Luiz Augusto von Dentz, linux-bluetooth, Gustavo F. Padovan On Tue, Aug 26, 2014 at 7:08 PM, Marcel Holtmann <marcel@holtmann.org> wrot= e: > Hi Artem, > >>>> please do not top post on this mailing list. It does break the reading= thread. >>>> >>>>> Here is hcitool info: >>>>> >>>>> BD Address: 10:B7:F6:01:31:ED >>>>> Device Name: Monster Clarity >>>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>>>> Manufacturer: Cambridge Silicon Radio (10) >>>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>>> <3-slot packets> >>>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>>>> >>>>> Label also says Precision Micro Bluetooth Speaker 100. >>>> >>>> normally all CSR based solutions should just work. Maybe this is just = a bad firmware. Are you sure that Connection Pending is really causing the = observed problem. It sounds strange to hit that on a CSR based speaker. >>> >>> I compared the logs from avtest and bluetoothd (attached earlier in >>> this thread). I think the only difference that could matter is this >>> Authorization Pending response. >> >> I've tested several devices with and without Defer Setup feature enabled= . >> >> Here is a list of devices, which successfully initiate A2DP >> connection, not depending on Defer Setup: >> Creative WP-350 Headset >> MiiKey Rythm >> JBL Micro Wireless >> HMDX Rave >> Plantronics BBfit >> Bose SoundLink Mobile speaker II >> SOL Tracks Air >> Sony MDR-1RBT >> >> Here is a list of devices, which fail to initiate A2DP connection with >> Defer Setup enabled, but work fine when Defer Setup is disabled: >> Monster Clarity HD >> Motorola S9-HD >> Sennheiser PX210 >> 2010 Toyota Prius > > are all of these CSR based devices? If so then it sounds like a batch of = broken CSR firmware. If not, then the L2CAP test cases might better be exte= nded to have a test case for this. It is dangerous if such a fundamental Bl= uetooth 1.1 feature is not working correctly. Yes, all these devices are CSR-based. >> There are no devices, which are working with Defer Setup, and not >> working without Defer Setup. So I didn't see any regression. >> >> As a result, 4 out of 12 devices do not connect as expected with Defer >> Setup enabled. I think we should consider disabling Defer Setup by >> default, at least for audio. > > I all cases this is the A2DP signaling channel that causes the problem? I= t is not the media channel that is required for streaming? Yes, exactly same scenario. The very first connection fails from speaker to source, which goes to AVDTP (PSM 25). > Our real problem is that we need Defer Setup to be able to cleanly reject= connections from devices that we do not know and do not want to talk to us= e. Especially if they are just not authorized to do so. > > Maybe we should use the proposal that Luiz had and just disconnect after = a timeout and try to establish the connection from our side. That might act= ually be useful as a workaround. An alternative option is that we delay the= connection pending message for some time and give userspace the chance to = respond with either read() or close(). That way we would send the correct a= nswer. However that timeout can only be really short since we need to keep = the L2CAP signaling working correctly. So it would only work for cases wher= e the daemon has all information to make a decision. If it asks the user, t= hen this is off limits. > > That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that m= ight be useful to mitigate this behavior as well. Unknown devices would be = blocked on the ACL level already. > > Regards > > Marcel > Thanks, Artem ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-27 6:33 ` Artem Rakhov @ 2014-08-27 18:34 ` Luiz Augusto von Dentz 2014-08-28 11:19 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-08-27 18:34 UTC (permalink / raw) To: Artem Rakhov; +Cc: Marcel Holtmann, linux-bluetooth, Gustavo F. Padovan Hi Artem, Marcel, On Wed, Aug 27, 2014 at 9:33 AM, Artem Rakhov <arakhov@chromium.org> wrote: > On Tue, Aug 26, 2014 at 7:08 PM, Marcel Holtmann <marcel@holtmann.org> wr= ote: >> Hi Artem, >> >>>>> please do not top post on this mailing list. It does break the readin= g thread. >>>>> >>>>>> Here is hcitool info: >>>>>> >>>>>> BD Address: 10:B7:F6:01:31:ED >>>>>> Device Name: Monster Clarity >>>>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>>>>> Manufacturer: Cambridge Silicon Radio (10) >>>>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>>>> <3-slot packets> >>>>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>>>>> >>>>>> Label also says Precision Micro Bluetooth Speaker 100. >>>>> >>>>> normally all CSR based solutions should just work. Maybe this is just= a bad firmware. Are you sure that Connection Pending is really causing the= observed problem. It sounds strange to hit that on a CSR based speaker. >>>> >>>> I compared the logs from avtest and bluetoothd (attached earlier in >>>> this thread). I think the only difference that could matter is this >>>> Authorization Pending response. >>> >>> I've tested several devices with and without Defer Setup feature enable= d. >>> >>> Here is a list of devices, which successfully initiate A2DP >>> connection, not depending on Defer Setup: >>> Creative WP-350 Headset >>> MiiKey Rythm >>> JBL Micro Wireless >>> HMDX Rave >>> Plantronics BBfit >>> Bose SoundLink Mobile speaker II >>> SOL Tracks Air >>> Sony MDR-1RBT >>> >>> Here is a list of devices, which fail to initiate A2DP connection with >>> Defer Setup enabled, but work fine when Defer Setup is disabled: >>> Monster Clarity HD >>> Motorola S9-HD >>> Sennheiser PX210 >>> 2010 Toyota Prius >> >> are all of these CSR based devices? If so then it sounds like a batch of= broken CSR firmware. If not, then the L2CAP test cases might better be ext= ended to have a test case for this. It is dangerous if such a fundamental B= luetooth 1.1 feature is not working correctly. > > Yes, all these devices are CSR-based. Well I have access to none of those which is kind nice. >>> There are no devices, which are working with Defer Setup, and not >>> working without Defer Setup. So I didn't see any regression. >>> >>> As a result, 4 out of 12 devices do not connect as expected with Defer >>> Setup enabled. I think we should consider disabling Defer Setup by >>> default, at least for audio. >> >> I all cases this is the A2DP signaling channel that causes the problem? = It is not the media channel that is required for streaming? > > Yes, exactly same scenario. The very first connection fails from > speaker to source, which goes to AVDTP (PSM 25). There are some other things to experiment, there seems to be possible to use ERTM nowadays, for signalling only, and while this does not exactly change in any way how we use authorization pending response it perhaps make a difference in terms of timing, if we are lucky, otherwise we can go with whitelist and retry. >> Our real problem is that we need Defer Setup to be able to cleanly rejec= t connections from devices that we do not know and do not want to talk to u= se. Especially if they are just not authorized to do so. >> >> Maybe we should use the proposal that Luiz had and just disconnect after= a timeout and try to establish the connection from our side. That might ac= tually be useful as a workaround. An alternative option is that we delay th= e connection pending message for some time and give userspace the chance to= respond with either read() or close(). That way we would send the correct = answer. However that timeout can only be really short since we need to keep= the L2CAP signaling working correctly. So it would only work for cases whe= re the daemon has all information to make a decision. If it asks the user, = then this is off limits. >> >> That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that = might be useful to mitigate this behavior as well. Unknown devices would be= blocked on the ACL level already. If whitelist for classic is to be based on the trusted list, which I assume it should be, then the kernel could accept the connection right away but then we need some mechanism to query if the whitelist has taken effect or maybe it is fine already since bt_io_accept does the following: if (!(pfd.revents & POLLOUT)) { if (read(sock, &c, 1) < 0) { ERROR_FAILED(err, "read", errno); return FALSE; } } So POLLOUT seems to be for checking if the socket has been accepted already, in case we have a older kernel we can only retry if authorization succeeds but that will probably only happen if the device happens to be trusted otherwise it will trigger the agent for user to authorize and it more likely the device will disconnect before the user can react cancelling the authorization. --=20 Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-27 18:34 ` Luiz Augusto von Dentz @ 2014-08-28 11:19 ` Luiz Augusto von Dentz 2014-08-28 20:37 ` Marcel Holtmann 0 siblings, 1 reply; 25+ messages in thread From: Luiz Augusto von Dentz @ 2014-08-28 11:19 UTC (permalink / raw) To: Artem Rakhov; +Cc: Marcel Holtmann, linux-bluetooth Hi Marcel, On Wed, Aug 27, 2014 at 9:34 PM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Artem, Marcel, > > On Wed, Aug 27, 2014 at 9:33 AM, Artem Rakhov <arakhov@chromium.org> wrot= e: >> On Tue, Aug 26, 2014 at 7:08 PM, Marcel Holtmann <marcel@holtmann.org> w= rote: >>> Hi Artem, >>> >>>>>> please do not top post on this mailing list. It does break the readi= ng thread. >>>>>> >>>>>>> Here is hcitool info: >>>>>>> >>>>>>> BD Address: 10:B7:F6:01:31:ED >>>>>>> Device Name: Monster Clarity >>>>>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>>>>>> Manufacturer: Cambridge Silicon Radio (10) >>>>>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>>>>> <3-slot packets> >>>>>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>>>>>> >>>>>>> Label also says Precision Micro Bluetooth Speaker 100. >>>>>> >>>>>> normally all CSR based solutions should just work. Maybe this is jus= t a bad firmware. Are you sure that Connection Pending is really causing th= e observed problem. It sounds strange to hit that on a CSR based speaker. >>>>> >>>>> I compared the logs from avtest and bluetoothd (attached earlier in >>>>> this thread). I think the only difference that could matter is this >>>>> Authorization Pending response. >>>> >>>> I've tested several devices with and without Defer Setup feature enabl= ed. >>>> >>>> Here is a list of devices, which successfully initiate A2DP >>>> connection, not depending on Defer Setup: >>>> Creative WP-350 Headset >>>> MiiKey Rythm >>>> JBL Micro Wireless >>>> HMDX Rave >>>> Plantronics BBfit >>>> Bose SoundLink Mobile speaker II >>>> SOL Tracks Air >>>> Sony MDR-1RBT >>>> >>>> Here is a list of devices, which fail to initiate A2DP connection with >>>> Defer Setup enabled, but work fine when Defer Setup is disabled: >>>> Monster Clarity HD >>>> Motorola S9-HD >>>> Sennheiser PX210 >>>> 2010 Toyota Prius >>> >>> are all of these CSR based devices? If so then it sounds like a batch o= f broken CSR firmware. If not, then the L2CAP test cases might better be ex= tended to have a test case for this. It is dangerous if such a fundamental = Bluetooth 1.1 feature is not working correctly. >> >> Yes, all these devices are CSR-based. > > Well I have access to none of those which is kind nice. > >>>> There are no devices, which are working with Defer Setup, and not >>>> working without Defer Setup. So I didn't see any regression. >>>> >>>> As a result, 4 out of 12 devices do not connect as expected with Defer >>>> Setup enabled. I think we should consider disabling Defer Setup by >>>> default, at least for audio. >>> >>> I all cases this is the A2DP signaling channel that causes the problem?= It is not the media channel that is required for streaming? >> >> Yes, exactly same scenario. The very first connection fails from >> speaker to source, which goes to AVDTP (PSM 25). > > There are some other things to experiment, there seems to be possible > to use ERTM nowadays, for signalling only, and while this does not > exactly change in any way how we use authorization pending response it > perhaps make a difference in terms of timing, if we are lucky, > otherwise we can go with whitelist and retry. > >>> Our real problem is that we need Defer Setup to be able to cleanly reje= ct connections from devices that we do not know and do not want to talk to = use. Especially if they are just not authorized to do so. >>> >>> Maybe we should use the proposal that Luiz had and just disconnect afte= r a timeout and try to establish the connection from our side. That might a= ctually be useful as a workaround. An alternative option is that we delay t= he connection pending message for some time and give userspace the chance t= o respond with either read() or close(). That way we would send the correct= answer. However that timeout can only be really short since we need to kee= p the L2CAP signaling working correctly. So it would only work for cases wh= ere the daemon has all information to make a decision. If it asks the user,= then this is off limits. >>> >>> That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that= might be useful to mitigate this behavior as well. Unknown devices would b= e blocked on the ACL level already. > > If whitelist for classic is to be based on the trusted list, which I > assume it should be, then the kernel could accept the connection right > away but then we need some mechanism to query if the whitelist has > taken effect or maybe it is fine already since bt_io_accept does the > following: > > if (!(pfd.revents & POLLOUT)) { > if (read(sock, &c, 1) < 0) { > ERROR_FAILED(err, "read", errno); > return FALSE; > } > } > > So POLLOUT seems to be for checking if the socket has been accepted > already, in case we have a older kernel we can only retry if > authorization succeeds but that will probably only happen if the > device happens to be trusted otherwise it will trigger the agent for > user to authorize and it more likely the device will disconnect before > the user can react cancelling the authorization. I was checking how whitelist actually works currently and in fact it is not based on trusted list but on persistency, but we could use action 2 for BREDR once they are marked as trusted but perhaps you guys had something else in mind while designing Add Device command. If we can't really reuse action 2, or have a dedicated action for trusted devices, then Im afraid it won't help in this specific problem. --=20 Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [A2DP] Incoming connections do not succeed 2014-08-28 11:19 ` Luiz Augusto von Dentz @ 2014-08-28 20:37 ` Marcel Holtmann 0 siblings, 0 replies; 25+ messages in thread From: Marcel Holtmann @ 2014-08-28 20:37 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Artem Rakhov, linux-bluetooth Hi Luiz, >>>>>>> please do not top post on this mailing list. It does break the reading thread. >>>>>>> >>>>>>>> Here is hcitool info: >>>>>>>> >>>>>>>> BD Address: 10:B7:F6:01:31:ED >>>>>>>> Device Name: Monster Clarity >>>>>>>> LMP Version: 2.1 (0x4) LMP Subversion: 0x189c >>>>>>>> Manufacturer: Cambridge Silicon Radio (10) >>>>>>>> Features page 0: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>>>>>> <3-slot packets> >>>>>>>> Features page 1: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83 >>>>>>>> >>>>>>>> Label also says Precision Micro Bluetooth Speaker 100. >>>>>>> >>>>>>> normally all CSR based solutions should just work. Maybe this is just a bad firmware. Are you sure that Connection Pending is really causing the observed problem. It sounds strange to hit that on a CSR based speaker. >>>>>> >>>>>> I compared the logs from avtest and bluetoothd (attached earlier in >>>>>> this thread). I think the only difference that could matter is this >>>>>> Authorization Pending response. >>>>> >>>>> I've tested several devices with and without Defer Setup feature enabled. >>>>> >>>>> Here is a list of devices, which successfully initiate A2DP >>>>> connection, not depending on Defer Setup: >>>>> Creative WP-350 Headset >>>>> MiiKey Rythm >>>>> JBL Micro Wireless >>>>> HMDX Rave >>>>> Plantronics BBfit >>>>> Bose SoundLink Mobile speaker II >>>>> SOL Tracks Air >>>>> Sony MDR-1RBT >>>>> >>>>> Here is a list of devices, which fail to initiate A2DP connection with >>>>> Defer Setup enabled, but work fine when Defer Setup is disabled: >>>>> Monster Clarity HD >>>>> Motorola S9-HD >>>>> Sennheiser PX210 >>>>> 2010 Toyota Prius >>>> >>>> are all of these CSR based devices? If so then it sounds like a batch of broken CSR firmware. If not, then the L2CAP test cases might better be extended to have a test case for this. It is dangerous if such a fundamental Bluetooth 1.1 feature is not working correctly. >>> >>> Yes, all these devices are CSR-based. >> >> Well I have access to none of those which is kind nice. >> >>>>> There are no devices, which are working with Defer Setup, and not >>>>> working without Defer Setup. So I didn't see any regression. >>>>> >>>>> As a result, 4 out of 12 devices do not connect as expected with Defer >>>>> Setup enabled. I think we should consider disabling Defer Setup by >>>>> default, at least for audio. >>>> >>>> I all cases this is the A2DP signaling channel that causes the problem? It is not the media channel that is required for streaming? >>> >>> Yes, exactly same scenario. The very first connection fails from >>> speaker to source, which goes to AVDTP (PSM 25). >> >> There are some other things to experiment, there seems to be possible >> to use ERTM nowadays, for signalling only, and while this does not >> exactly change in any way how we use authorization pending response it >> perhaps make a difference in terms of timing, if we are lucky, >> otherwise we can go with whitelist and retry. >> >>>> Our real problem is that we need Defer Setup to be able to cleanly reject connections from devices that we do not know and do not want to talk to use. Especially if they are just not authorized to do so. >>>> >>>> Maybe we should use the proposal that Luiz had and just disconnect after a timeout and try to establish the connection from our side. That might actually be useful as a workaround. An alternative option is that we delay the connection pending message for some time and give userspace the chance to respond with either read() or close(). That way we would send the correct answer. However that timeout can only be really short since we need to keep the L2CAP signaling working correctly. So it would only work for cases where the daemon has all information to make a decision. If it asks the user, then this is off limits. >>>> >>>> That said, Linux 3.17 is allowing us to use a whitelist for BR/EDR that might be useful to mitigate this behavior as well. Unknown devices would be blocked on the ACL level already. >> >> If whitelist for classic is to be based on the trusted list, which I >> assume it should be, then the kernel could accept the connection right >> away but then we need some mechanism to query if the whitelist has >> taken effect or maybe it is fine already since bt_io_accept does the >> following: >> >> if (!(pfd.revents & POLLOUT)) { >> if (read(sock, &c, 1) < 0) { >> ERROR_FAILED(err, "read", errno); >> return FALSE; >> } >> } >> >> So POLLOUT seems to be for checking if the socket has been accepted >> already, in case we have a older kernel we can only retry if >> authorization succeeds but that will probably only happen if the >> device happens to be trusted otherwise it will trigger the agent for >> user to authorize and it more likely the device will disconnect before >> the user can react cancelling the authorization. > > I was checking how whitelist actually works currently and in fact it > is not based on trusted list but on persistency, but we could use > action 2 for BREDR once they are marked as trusted but perhaps you > guys had something else in mind while designing Add Device command. If > we can't really reuse action 2, or have a dedicated action for trusted > devices, then Im afraid it won't help in this specific problem. the action 0x02 is not defined or implemented for BR/EDR devices. Regards Marcel ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2014-08-28 20:37 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-26 1:33 [A2DP] Incoming connections do not succeed Artem Rakhov 2014-07-28 8:21 ` Luiz Augusto von Dentz 2014-07-29 0:24 ` Artem Rakhov 2014-07-29 5:16 ` Artem Rakhov 2014-07-29 5:29 ` Marcel Holtmann 2014-08-08 7:32 ` Artem Rakhov 2014-08-10 7:32 ` Luiz Augusto von Dentz 2014-08-11 6:07 ` Michal Labedzki 2014-08-18 7:11 ` Artem Rakhov 2014-08-20 22:52 ` Artem Rakhov 2014-08-20 22:54 ` Artem Rakhov 2014-08-21 6:42 ` Artem Rakhov 2014-08-21 8:38 ` Luiz Augusto von Dentz 2014-08-21 13:33 ` Marcel Holtmann 2014-08-21 13:53 ` Luiz Augusto von Dentz 2014-08-21 14:28 ` Marcel Holtmann 2014-08-21 19:16 ` Artem Rakhov 2014-08-21 20:24 ` Marcel Holtmann 2014-08-21 21:31 ` Artem Rakhov 2014-08-27 1:11 ` Artem Rakhov 2014-08-27 2:08 ` Marcel Holtmann 2014-08-27 6:33 ` Artem Rakhov 2014-08-27 18:34 ` Luiz Augusto von Dentz 2014-08-28 11:19 ` Luiz Augusto von Dentz 2014-08-28 20:37 ` Marcel Holtmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.