Keeping ACL link around after DBUS CreateBonding()

Keeping ACL link around after DBUS CreateBonding()

[Nick Pelly]

Marcel/Johan:

I have memories of one of you talking about a custom change to bluez
to not immediately drop the ACL link once DBUS CreateBonding() has
finished (so that SDP can then be done on that link).

Do you know the patch to do this? I am currently experimenting with
changing the timer expiry in hci_conn_put() for disc_timer. Maybe
there's a nicer way.

Thanks
Nick

Re: Keeping ACL link around after DBUS CreateBonding()

[Marcel Holtmann]

Hi Nick,

> I have memories of one of you talking about a custom change to bluez
> to not immediately drop the ACL link once DBUS CreateBonding() has
> finished (so that SDP can then be done on that link).
> 
> Do you know the patch to do this? I am currently experimenting with
> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
> there's a nicer way.

do you have a trace in BTSnoop format for me. We are using L2CAP raw
sockets for bonding and thus the default 2 seconds disconnect timeout
applies. Enough time to get SDP started on the same link. If the remote
side however decides to disconnect us, we are out of luck.

Regards

Marcel

Re: Keeping ACL link around after DBUS CreateBonding()

[Nick Pelly]

On Thu, Oct 2, 2008 at 11:36 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Nick,
>
>> I have memories of one of you talking about a custom change to bluez
>> to not immediately drop the ACL link once DBUS CreateBonding() has
>> finished (so that SDP can then be done on that link).
>>
>> Do you know the patch to do this? I am currently experimenting with
>> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
>> there's a nicer way.
>
> do you have a trace in BTSnoop format for me. We are using L2CAP raw
> sockets for bonding and thus the default 2 seconds disconnect timeout
> applies. Enough time to get SDP started on the same link. If the remote
> side however decides to disconnect us, we are out of luck.

For this situation the ACL connection is not complete, so the 10ms
timeout applies. I have a patch to use the 2 second timeout code path
for both connecting and connected. I wonder if this would be useful in
mainline, or if this is just a strange behavior of our BRF6300 (it
completes pin code and link key before the ACL link is reported as
connected). I'll send you some logs tomorrow if that would still help.

Nick

Re: Keeping ACL link around after DBUS CreateBonding()

[Marcel Holtmann]

Hi Nick,

> >> I have memories of one of you talking about a custom change to bluez
> >> to not immediately drop the ACL link once DBUS CreateBonding() has
> >> finished (so that SDP can then be done on that link).
> >>
> >> Do you know the patch to do this? I am currently experimenting with
> >> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
> >> there's a nicer way.
> >
> > do you have a trace in BTSnoop format for me. We are using L2CAP raw
> > sockets for bonding and thus the default 2 seconds disconnect timeout
> > applies. Enough time to get SDP started on the same link. If the remote
> > side however decides to disconnect us, we are out of luck.
> 
> For this situation the ACL connection is not complete, so the 10ms
> timeout applies. I have a patch to use the 2 second timeout code path
> for both connecting and connected. I wonder if this would be useful in
> mainline, or if this is just a strange behavior of our BRF6300 (it
> completes pin code and link key before the ACL link is reported as
> connected). I'll send you some logs tomorrow if that would still help.

that is not strange behavior. That is just a device in security mode 3.
The important question is who disconnects the link.

Regards

Marcel

Re: Keeping ACL link around after DBUS CreateBonding()

[Nick Pelly]

On Fri, Oct 3, 2008 at 8:56 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Nick,
>
>> >> I have memories of one of you talking about a custom change to bluez
>> >> to not immediately drop the ACL link once DBUS CreateBonding() has
>> >> finished (so that SDP can then be done on that link).
>> >>
>> >> Do you know the patch to do this? I am currently experimenting with
>> >> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
>> >> there's a nicer way.
>> >
>> > do you have a trace in BTSnoop format for me. We are using L2CAP raw
>> > sockets for bonding and thus the default 2 seconds disconnect timeout
>> > applies. Enough time to get SDP started on the same link. If the remote
>> > side however decides to disconnect us, we are out of luck.
>>
>> For this situation the ACL connection is not complete, so the 10ms
>> timeout applies. I have a patch to use the 2 second timeout code path
>> for both connecting and connected. I wonder if this would be useful in
>> mainline, or if this is just a strange behavior of our BRF6300 (it
>> completes pin code and link key before the ACL link is reported as
>> connected). I'll send you some logs tomorrow if that would still help.
>
> that is not strange behavior. That is just a device in security mode 3.
> The important question is who disconnects the link.

We (bluez kernel stack) disconnect the link due to the 10 ms timeout
that applies when the ACL link is in CONNECT. Here is a patch to use
the 2 second time out during CONNECT phase as well as CONNECTED. Does
this patch seem reasonable? It looks like just CONNECT || CONNECTED is
sufficient, but there are other modes like CONNECT2.

commit 0876dd6c7c3c5827c21bb0804453a249de234953
Author: Nick Pelly <npelly@google.com>
Date:   Fri Oct 3 16:07:50 2008 -0700

    bluetooth: Drop ACL link after 2 seconds not 10 ms when connecting.

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 3446bc9..a2b0e09 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -341,7 +341,7 @@ static inline void hci_conn_put(struct hci_conn *conn)
                unsigned long timeo;
                if (conn->type == ACL_LINK) {
                        del_timer(&conn->idle_timer);
-                       if (conn->state == BT_CONNECTED) {
+                       if (conn->state == BT_CONNECTED || conn->state
== BT_CONNECT) {
                                timeo = msecs_to_jiffies(HCI_DISCONN_TIMEOUT);
                                if (!conn->out)
                                        timeo *= 2;



Nick

Re: Keeping ACL link around after DBUS CreateBonding()

[Marcel Holtmann]

Hi Nick,

> >> >> I have memories of one of you talking about a custom change to bluez
> >> >> to not immediately drop the ACL link once DBUS CreateBonding() has
> >> >> finished (so that SDP can then be done on that link).
> >> >>
> >> >> Do you know the patch to do this? I am currently experimenting with
> >> >> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
> >> >> there's a nicer way.
> >> >
> >> > do you have a trace in BTSnoop format for me. We are using L2CAP raw
> >> > sockets for bonding and thus the default 2 seconds disconnect timeout
> >> > applies. Enough time to get SDP started on the same link. If the remote
> >> > side however decides to disconnect us, we are out of luck.
> >>
> >> For this situation the ACL connection is not complete, so the 10ms
> >> timeout applies. I have a patch to use the 2 second timeout code path
> >> for both connecting and connected. I wonder if this would be useful in
> >> mainline, or if this is just a strange behavior of our BRF6300 (it
> >> completes pin code and link key before the ACL link is reported as
> >> connected). I'll send you some logs tomorrow if that would still help.
> >
> > that is not strange behavior. That is just a device in security mode 3.
> > The important question is who disconnects the link.
> 
> We (bluez kernel stack) disconnect the link due to the 10 ms timeout
> that applies when the ACL link is in CONNECT. Here is a patch to use
> the 2 second time out during CONNECT phase as well as CONNECTED. Does
> this patch seem reasonable? It looks like just CONNECT || CONNECTED is
> sufficient, but there are other modes like CONNECT2.

I really need to have a BTSnoop trace of this. I am not sure why you end
up in a situation where the timer is active anyway. What kernel version
are you running? Can you re-produce it with a 2.6.27-rc8 one?

The CONNECT2 is the re-try case for concurrent connection attempts where
link manager does not queue up the create connection.

Regards

Marcel

Re: Keeping ACL link around after DBUS CreateBonding()

[Nick Pelly]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

On Mon, Oct 6, 2008 at 6:26 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Nick,
>
>> >> >> I have memories of one of you talking about a custom change to bluez
>> >> >> to not immediately drop the ACL link once DBUS CreateBonding() has
>> >> >> finished (so that SDP can then be done on that link).
>> >> >>
>> >> >> Do you know the patch to do this? I am currently experimenting with
>> >> >> changing the timer expiry in hci_conn_put() for disc_timer. Maybe
>> >> >> there's a nicer way.
>> >> >
>> >> > do you have a trace in BTSnoop format for me. We are using L2CAP raw
>> >> > sockets for bonding and thus the default 2 seconds disconnect timeout
>> >> > applies. Enough time to get SDP started on the same link. If the remote
>> >> > side however decides to disconnect us, we are out of luck.
>> >>
>> >> For this situation the ACL connection is not complete, so the 10ms
>> >> timeout applies. I have a patch to use the 2 second timeout code path
>> >> for both connecting and connected. I wonder if this would be useful in
>> >> mainline, or if this is just a strange behavior of our BRF6300 (it
>> >> completes pin code and link key before the ACL link is reported as
>> >> connected). I'll send you some logs tomorrow if that would still help.
>> >
>> > that is not strange behavior. That is just a device in security mode 3.
>> > The important question is who disconnects the link.
>>
>> We (bluez kernel stack) disconnect the link due to the 10 ms timeout
>> that applies when the ACL link is in CONNECT. Here is a patch to use
>> the 2 second time out during CONNECT phase as well as CONNECTED. Does
>> this patch seem reasonable? It looks like just CONNECT || CONNECTED is
>> sufficient, but there are other modes like CONNECT2.
>
> I really need to have a BTSnoop trace of this. I am not sure why you end
> up in a situation where the timer is active anyway. What kernel version
> are you running? Can you re-produce it with a 2.6.27-rc8 one?
>

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.

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).

This is from a 2.6.25 kernel. I dont have easy access to 2.6.27 to
test at the moment. I dont think any code has changed in this area.



> The CONNECT2 is the re-try case for concurrent connection attempts where
> link manager does not queue up the create connection.
>
> Regards
>
> Marcel
>
>
>

[-- Attachment #2: dump.log --]
[-- Type: application/octet-stream, Size: 543 bytes --]

Re: Keeping ACL link around after DBUS CreateBonding()

[Marcel Holtmann]

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