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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
