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@xxxxxxxxxxxx> 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:
bluetooth_packet.btsnoop
Description: Binary data