Re: Keeping ACL link around after DBUS CreateBonding()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nick,

> Attached is the btsnoop from the CreateBonding()
> 
> Note the "Create Connection Cancel" right after completing bonding.
> This is what this patch tries to address - allow 2 seconds before
> disconnecting the ACL link instead of 10 ms for this scenario.

so the actual questions is why we end up here:

> HCI Event: Link Key Notification (0x18) plen 23
    bdaddr 00:19:7F:64:DA:C5 key E3E8A7783875D177851DC9F0EEEB474D type 0
    Type: Combination Key
< HCI Command: Create Connection Cancel (0x01|0x0008) plen 6
    bdaddr 00:19:7F:64:DA:C5
< HCI Command: Create Connection Cancel (0x01|0x0008) plen 6
    bdaddr 00:19:7F:64:DA:C5
> HCI Event: Command Complete (0x0e) plen 10
    Create Connection Cancel (0x01|0x0008) ncmd 1
    status 0x00 bdaddr 00:19:7F:64:DA:C5
> HCI Event: Command Complete (0x0e) plen 10
    Create Connection Cancel (0x01|0x0008) ncmd 1
    status 0x00 bdaddr 00:19:7F:64:DA:C5
> HCI Event: Connect Complete (0x03) plen 11
    status 0x02 handle 1 bdaddr 00:19:7F:64:DA:C5 type ACL encrypt 0x01
    Error: Unknown Connection Identifier

The problem is not the kernel since the kernel is doing the right thing
here. If the last user goes away and we haven't established ACL then we
cancel it instead of letting it timeout.

So the CreateBonding is actually broken here. CreateBonding should only
close the L2CAP raw socket (the one we use for bonding), when we get
Auth Complete (in that case 2 seconds apply) or when we get the Link Key
Notification before Connect Complete, it has to wait until Connect
Complete to close it.

Johan, please check if your modified code in 4.x actually does the right
thing for security mode 3. Or if we still have the same issue.

> Also note that the "Create Connection Cancel" takes 40 seconds to
> return from the BRF6300. To me this looks like a unrelated issue with
> the TI chip (and I have a separate conversation going on with TI about
> it).

The double Create Connection Cancel and not rejecting one with an error
code is an issue of the TI chip. It should not allow that. Question
still is why do we send it twice.

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

[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux