linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrzej Kaczmarek <andrzejk@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>,
	linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH v2] Bluetooth: Use hci_conn data to handle failed LE Connection Complete
Date: Wed, 16 May 2012 23:44:51 +0200	[thread overview]
Message-ID: <CA+6KyKZ0vrPHoXXfWwJdiVLDR+59azRwWMhJbjndM+Aw_dKSwA@mail.gmail.com> (raw)
In-Reply-To: <1337202331.5970.269.camel@aeonflux>

Hi Marcel,

2012/5/16 Marcel Holtmann <marcel@holtmann.org>:
>> =A0 =A0 =A0 hci_dev_lock(hdev);
>>
>> + =A0 =A0 if (ev->status) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 conn =3D hci_conn_hash_lookup_state(hdev, LE_L=
INK, BT_CONNECT);
>> + =A0 =A0 =A0 =A0 =A0 =A0 if (!conn)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto unlock;
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 mgmt_connect_failed(hdev, &conn->dst, conn->ty=
pe,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 conn->=
dst_type, ev->status);
>> + =A0 =A0 =A0 =A0 =A0 =A0 hci_proto_connect_cfm(conn, ev->status);
>> + =A0 =A0 =A0 =A0 =A0 =A0 conn->state =3D BT_CLOSED;
>> + =A0 =A0 =A0 =A0 =A0 =A0 hci_conn_del(conn);
>> + =A0 =A0 =A0 =A0 =A0 =A0 goto unlock;
>> + =A0 =A0 }
>> +
>> =A0 =A0 =A0 conn =3D hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr)=
;
>> =A0 =A0 =A0 if (!conn) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 conn =3D hci_conn_add(hdev, LE_LINK, &ev->bd=
addr);
>
> this change is wrong. We are now treating every single adapter as being
> broken. That is not acceptable.

Why do you think these adapters are broken? As I explained in cover
letter for v1, spec does not require peer address to be provided in
Connection Complete which is reasonable since we can only have one
pending connection request. Also as Claudio and Andre noticed such
behaviour could be to simplify whitelist implementation - in case of
connection request using whitelist it does not make sense to include
specific peer address in event.

> We should only add a tweak if the BD_ADDR parameter is BDADDR_ANY and
> not as a general rule. In addition if we do this, we need to print a
> warning to dmesg to make this known.

Perhaps we can just add warning in case BD_ADDR is not BDADDR_ANY and
we cannot find hci_conn for it - in such case most probably something
went wrong.

BR,
Andrzej

  reply	other threads:[~2012-05-16 21:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16 20:55 [PATCH v2] Bluetooth: Use hci_conn data to handle failed LE Connection Complete Andrzej Kaczmarek
2012-05-16 21:05 ` Marcel Holtmann
2012-05-16 21:44   ` Andrzej Kaczmarek [this message]
2012-05-16 21:48     ` Marcel Holtmann
2012-05-17  8:05       ` Andrzej Kaczmarek
2012-05-21 22:30         ` Andre Guedes
2012-05-25  6:55           ` Marcel Holtmann
2012-05-30 13:43             ` Andrzej Kaczmarek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+6KyKZ0vrPHoXXfWwJdiVLDR+59azRwWMhJbjndM+Aw_dKSwA@mail.gmail.com \
    --to=andrzejk@gmail.com \
    --cc=andrzej.kaczmarek@tieto.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).