* Re: [RFC] Proposal to distinguish address device types
From: Gustavo F. Padovan @ 2011-04-15 18:47 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: johan.hedberg, marcel, linux-bluetooth
In-Reply-To: <1302892422-32206-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
* Claudio Takahasi <claudio.takahasi@openbossa.org> [2011-04-15 15:33:42 -0300]:
> Device type is input to decide how to establish the L2CAP connection.
> For LE devices fixed channel ID 4 is set, otherwise PSM should be set
> for basic rate connections. LE public and random constants are misused
> for discovery, however I don't see advantage of defining basic rate and
> LE values only.
>
> Based on jhe/master:
> git://git.kernel.org/pub/scm/linux/kernel/git/jh/linux-2.6.git
>
> Opinions?
> ---
> include/net/bluetooth/bluetooth.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 4 ++--
> include/net/bluetooth/mgmt.h | 1 +
> net/bluetooth/hci_event.c | 16 ++++++++--------
> net/bluetooth/mgmt.c | 5 +++--
> 5 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 4375043..b91eec9 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -94,6 +94,12 @@ typedef struct {
> #define BDADDR_ANY (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
> #define BDADDR_LOCAL (&(bdaddr_t) {{0, 0, 0, 0xff, 0xff, 0xff}})
>
> +enum {
> + BDADDR_TYPE_BR = 0,
As we going to differentiate this, can't we separate BR and BR/EDR?
Or maybe not once most of the device today should be BR/EDR.
> + BDADDR_TYPE_LE_PUBLIC,
> + BRADDR_TYPE_LE_RANDOM
> +};
> +
> /* Copy, swap, convert BD Address */
> static inline int bacmp(bdaddr_t *ba1, bdaddr_t *ba2)
> {
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 8200704..b357346 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -808,8 +808,8 @@ int mgmt_auth_failed(u16 index, bdaddr_t *bdaddr, u8 status);
> int mgmt_set_local_name_complete(u16 index, u8 *name, u8 status);
> int mgmt_read_local_oob_data_reply_complete(u16 index, u8 *hash, u8 *randomizer,
> u8 status);
> -int mgmt_device_found(u16 index, bdaddr_t *bdaddr, u8 *dev_class, s8 rssi,
> - u8 *eir);
> +int mgmt_device_found(u16 index, bdaddr_t *bdaddr, u8 bdaddr_type,
> + u8 *dev_class, s8 rssi, u8 *eir);
> int mgmt_remote_name(u16 index, bdaddr_t *bdaddr, u8 *name);
> int mgmt_periodic_inq_complete(u16 index, u8 status);
> int mgmt_exit_periodic_inq_complete(u16 index, u8 status);
> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
> index 2a70541..c299f6a 100644
> --- a/include/net/bluetooth/mgmt.h
> +++ b/include/net/bluetooth/mgmt.h
> @@ -281,6 +281,7 @@ struct mgmt_ev_local_name_changed {
> #define MGMT_EV_DEVICE_FOUND 0x0012
> struct mgmt_ev_device_found {
> bdaddr_t bdaddr;
> + __u8 bdaddr_type;
> __u8 dev_class[3];
> __s8 rssi;
> __u8 eir[HCI_MAX_EIR_LENGTH];
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index ded8e0c..997d8f6 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1285,8 +1285,8 @@ static inline void hci_inquiry_result_evt(struct hci_dev *hdev, struct sk_buff *
> if (!test_bit(HCI_MGMT, &hdev->flags))
> continue;
>
> - mgmt_device_found(hdev->id, &info->bdaddr, info->dev_class, 0,
> - NULL);
> + mgmt_device_found(hdev->id, &info->bdaddr, BDADDR_TYPE_BR,
> + info->dev_class, 0, NULL);
>
> if (test_bit(HCI_DISCOVERY, &hdev->flags))
> hci_add_found_device(hdev, &info->bdaddr, 0x00);
> @@ -2257,8 +2257,8 @@ static inline void hci_inquiry_result_with_rssi_evt(struct hci_dev *hdev, struct
> continue;
>
> mgmt_device_found(hdev->id, &info->bdaddr,
> - info->dev_class, info->rssi,
> - NULL);
> + BDADDR_TYPE_BR, info->dev_class,
> + info->rssi, NULL);
>
> if (!test_bit(HCI_DISCOVERY, &hdev->flags))
> continue;
> @@ -2283,8 +2283,8 @@ static inline void hci_inquiry_result_with_rssi_evt(struct hci_dev *hdev, struct
> continue;
>
> mgmt_device_found(hdev->id, &info->bdaddr,
> - info->dev_class, info->rssi,
> - NULL);
> + BDADDR_TYPE_BR, info->dev_class,
> + info->rssi, NULL);
>
> if (!test_bit(HCI_DISCOVERY, &hdev->flags))
> continue;
> @@ -2465,8 +2465,8 @@ static inline void hci_extended_inquiry_result_evt(struct hci_dev *hdev, struct
> if (!test_bit(HCI_MGMT, &hdev->flags))
> continue;
>
> - mgmt_device_found(hdev->id, &info->bdaddr, info->dev_class,
> - info->rssi, info->data);
> + mgmt_device_found(hdev->id, &info->bdaddr, BDADDR_TYPE_BR,
> + info->dev_class, info->rssi, info->data);
>
> if (!test_bit(HCI_DISCOVERY, &hdev->flags))
> continue;
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 2b20ee9..ad673f2 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -2157,14 +2157,15 @@ int mgmt_read_local_oob_data_reply_complete(u16 index, u8 *hash, u8 *randomizer,
> return err;
> }
>
> -int mgmt_device_found(u16 index, bdaddr_t *bdaddr, u8 *dev_class, s8 rssi,
> - u8 *eir)
> +int mgmt_device_found(u16 index, bdaddr_t *bdaddr, u8 bdaddr_type,
> + u8 *dev_class, s8 rssi, u8 *eir)
> {
> struct mgmt_ev_device_found ev;
>
> memset(&ev, 0, sizeof(ev));
>
> bacpy(&ev.bdaddr, bdaddr);
> + ev.bdaddr_type = bdaddr_type;
> memcpy(ev.dev_class, dev_class, sizeof(ev.dev_class));
> ev.rssi = rssi;
Otherwise looks good.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] bluetooth: fix shutdown on SCO sockets
From: Gustavo F. Padovan @ 2011-04-15 18:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1302271841-12127-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
* Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-04-08 17:10:41 +0300]:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> shutdown should wait for SCO link to be properly disconnected before
> detroying the socket, otherwise an application using the socket may
> assume link is properly disconnected before it really happens which
> can be a problem when e.g synchronizing profile switch.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
I applied it, but in bluetooth-next. Let's see its behaviour there and if no
problems show up we can move it to bluetooth-2.6
> ---
> net/bluetooth/sco.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index 42fdffd..94954c7 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -369,6 +369,15 @@ static void __sco_sock_close(struct sock *sk)
>
> case BT_CONNECTED:
> case BT_CONFIG:
> + if (sco_pi(sk)->conn) {
> + sk->sk_state = BT_DISCONN;
> + sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT);
> + hci_conn_put(sco_pi(sk)->conn->hcon);
> + sco_pi(sk)->conn = NULL;
> + } else
> + sco_chan_del(sk, ECONNRESET);
> + break;
> +
> case BT_CONNECT:
> case BT_DISCONN:
> sco_chan_del(sk, ECONNRESET);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: Wrong timeout when connecting to device with removed pairing
From: Gustavo F. Padovan @ 2011-04-15 19:22 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <BANLkTinfkhcfYu_L+5B_LkQVZyp8VdnnBw@mail.gmail.com>
Hi Luiz,
* Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-04-12 14:36:01 +0300]:
> Apparently this is a regression caused by commit
> 769be974d0c7b4fe1a52f9cdaad22259b60953f7 - [Bluetooth] Use ACL config
> stage to retrieve remote features, when receiving pincode request in a
> new connection the state will be BT_CONFIG so HCI_PAIRING_TIMEOUT is
> never set to the connection, this could be reproduced by removing a
> link key in the remote side and trying to connect:
>
> 2011-04-05 12:11:37.070953 < HCI Command: Authentication Requested
> (0x01|0x0011) plen 2
> handle 1
> 2011-04-05 12:11:37.071686 > HCI Event: Command Status (0x0f) plen 4
> Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> 2011-04-05 12:11:37.071838 > HCI Event: Link Key Request (0x17) plen 6
> bdaddr 00:1F:E1:EB:B9:CB
> 2011-04-05 12:11:37.075073 < HCI Command: Link Key Request Reply
> (0x01|0x000b) plen 22
> bdaddr 00:1F:E1:EB:B9:CB key 92BA9EAD06542B0600457C609B8F5395
> 2011-04-05 12:11:37.075775 > HCI Event: Command Complete (0x0e) plen 10
> Link Key Request Reply (0x01|0x000b) ncmd 1
> status 0x00 bdaddr 00:1F:E1:EB:B9:CB
> 2011-04-05 12:11:37.087005 > HCI Event: PIN Code Request (0x16) plen 6
> bdaddr 00:1F:E1:EB:B9:CB
> 2011-04-05 12:11:39.038849 < ACL data: handle 1 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x00a9 scid 0x0040
> 2011-04-05 12:11:39.100647 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 1 packets 1
> 2011-04-05 12:11:39.100830 > ACL data: handle 1 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x00a9 scid 0x0040
> 2011-04-05 12:11:40.433624 > HCI Event: Auth Complete (0x06) plen 3
> status 0x13 handle 1
> Error: Remote User Terminated Connection
> 2011-04-05 12:11:40.437774 > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 1 reason 0x13
> Reason: Remote User Terminated Connection
>
> I think the following patch might fix it:
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 3fbfa50..abdc4de 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1973,10 +1973,14 @@ static inline void hci_pin_code_request_evt(struct
> hci_dev *hdev, struct sk_buff
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
> - if (conn && conn->state == BT_CONNECTED) {
> - hci_conn_hold(conn);
> + if (conn) {
> conn->disc_timeout = HCI_PAIRING_TIMEOUT;
> - hci_conn_put(conn);
> +
> + /* Update disconnect timer */
> + if (conn->state == BT_CONNECTED) {
> + hci_conn_hold(conn);
> + hci_conn_put(conn);
I think these two line can be:
mod_timer(&conn->disc_timer, jiffies + HCI_PAIRING_TIMEOUT);
The two main difference are that here we don't delete the idle_timer, but it
isn't used anywhere, so I think we can delete it. Also we don't double the
timeout value when !conn->out
from hci_conn_put():
timeo = msecs_to_jiffies(conn->disc_timeout);
if (!conn->out)
timeo *= 2;
I still don't know why we double it.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: Wrong timeout when connecting to device with removed pairing
From: Gustavo F. Padovan @ 2011-04-15 19:28 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20110415192258.GC2359@joana>
* Gustavo F. Padovan <padovan@profusion.mobi> [2011-04-15 16:22:58 -0300]:
> Hi Luiz,
>
> * Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-04-12 14:36:01 +0300]:
>
> > Apparently this is a regression caused by commit
> > 769be974d0c7b4fe1a52f9cdaad22259b60953f7 - [Bluetooth] Use ACL config
> > stage to retrieve remote features, when receiving pincode request in a
> > new connection the state will be BT_CONFIG so HCI_PAIRING_TIMEOUT is
> > never set to the connection, this could be reproduced by removing a
> > link key in the remote side and trying to connect:
> >
> > 2011-04-05 12:11:37.070953 < HCI Command: Authentication Requested
> > (0x01|0x0011) plen 2
> > handle 1
> > 2011-04-05 12:11:37.071686 > HCI Event: Command Status (0x0f) plen 4
> > Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> > 2011-04-05 12:11:37.071838 > HCI Event: Link Key Request (0x17) plen 6
> > bdaddr 00:1F:E1:EB:B9:CB
> > 2011-04-05 12:11:37.075073 < HCI Command: Link Key Request Reply
> > (0x01|0x000b) plen 22
> > bdaddr 00:1F:E1:EB:B9:CB key 92BA9EAD06542B0600457C609B8F5395
> > 2011-04-05 12:11:37.075775 > HCI Event: Command Complete (0x0e) plen 10
> > Link Key Request Reply (0x01|0x000b) ncmd 1
> > status 0x00 bdaddr 00:1F:E1:EB:B9:CB
> > 2011-04-05 12:11:37.087005 > HCI Event: PIN Code Request (0x16) plen 6
> > bdaddr 00:1F:E1:EB:B9:CB
> > 2011-04-05 12:11:39.038849 < ACL data: handle 1 flags 0x00 dlen 12
> > L2CAP(s): Disconn req: dcid 0x00a9 scid 0x0040
> > 2011-04-05 12:11:39.100647 > HCI Event: Number of Completed Packets
> > (0x13) plen 5
> > handle 1 packets 1
> > 2011-04-05 12:11:39.100830 > ACL data: handle 1 flags 0x02 dlen 12
> > L2CAP(s): Disconn rsp: dcid 0x00a9 scid 0x0040
> > 2011-04-05 12:11:40.433624 > HCI Event: Auth Complete (0x06) plen 3
> > status 0x13 handle 1
> > Error: Remote User Terminated Connection
> > 2011-04-05 12:11:40.437774 > HCI Event: Disconn Complete (0x05) plen 4
> > status 0x00 handle 1 reason 0x13
> > Reason: Remote User Terminated Connection
> >
> > I think the following patch might fix it:
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 3fbfa50..abdc4de 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -1973,10 +1973,14 @@ static inline void hci_pin_code_request_evt(struct
> > hci_dev *hdev, struct sk_buff
> > hci_dev_lock(hdev);
> >
> > conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
> > - if (conn && conn->state == BT_CONNECTED) {
> > - hci_conn_hold(conn);
> > + if (conn) {
> > conn->disc_timeout = HCI_PAIRING_TIMEOUT;
> > - hci_conn_put(conn);
> > +
> > + /* Update disconnect timer */
> > + if (conn->state == BT_CONNECTED) {
> > + hci_conn_hold(conn);
> > + hci_conn_put(conn);
>
> I think these two line can be:
>
> mod_timer(&conn->disc_timer, jiffies + HCI_PAIRING_TIMEOUT);
>
>
> The two main difference are that here we don't delete the idle_timer, but it
> isn't used anywhere, so I think we can delete it.
My mistake, idle_timer is actually used, I forgot to look hci_conn.c
> Also we don't double the
> timeout value when !conn->out
>
> from hci_conn_put():
>
> timeo = msecs_to_jiffies(conn->disc_timeout);
> if (!conn->out)
> timeo *= 2;
>
> I still don't know why we double it.
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC 2/2] Bluetooth: Add support for returning the encryption key size
From: Marcel Holtmann @ 2011-04-16 0:57 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth, johan.hedberg
In-Reply-To: <1302825888-5359-3-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
> This will be useful when userspace wants to restrict some kinds of
> operations based on the length of the key size used to encrypt the
> link.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> include/net/bluetooth/bluetooth.h | 1 +
> net/bluetooth/l2cap_sock.c | 4 ++++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index acf186d..28ae91a 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -56,6 +56,7 @@
> #define BT_SECURITY 4
> struct bt_security {
> __u8 level;
> + __u8 key_size;
> };
there is one thing we need to keep in mind. Who is enforcing the
encryption key size and triggers are re-pairing if needed? Do we wanna
do that inside kernel space or have userspace involved?
Essentially besides maybe exporting the current encryption key size, you
also wanna enforce a minium encryption key size.
We can do this with this socket option in one go. I am fine with that,
but we need to have a way to ensure minium encryption key size or 0 if
we do not care.
And of course the same now applies for PIN code length. Even if with
Simple Pairing this does not matter anymore. For Legacy Pairing this is
still relevant.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 0/4] hcimgmt: command line tool for mgmt interface
From: Marcel Holtmann @ 2011-04-16 0:59 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1302890265-15649-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicious,
> When the mgmt interface was first proposed Johan sent a patch
> that introduced this tool, I updated it for the current MGMT API
> and added a couple new commands.
overall I like to have a tool called bt in similar fashion like iw, ip
etc. And I really want the hci* prefix getting out of tools namespace.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] Proposal to distinguish address device types
From: Marcel Holtmann @ 2011-04-16 1:03 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Claudio Takahasi, johan.hedberg, linux-bluetooth
In-Reply-To: <20110415184728.GA2359@joana>
Hi Claudio,
> > Device type is input to decide how to establish the L2CAP connection.
> > For LE devices fixed channel ID 4 is set, otherwise PSM should be set
> > for basic rate connections. LE public and random constants are misused
> > for discovery, however I don't see advantage of defining basic rate and
> > LE values only.
> >
> > Based on jhe/master:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jh/linux-2.6.git
> >
> > Opinions?
> > ---
> > include/net/bluetooth/bluetooth.h | 6 ++++++
> > include/net/bluetooth/hci_core.h | 4 ++--
> > include/net/bluetooth/mgmt.h | 1 +
> > net/bluetooth/hci_event.c | 16 ++++++++--------
> > net/bluetooth/mgmt.c | 5 +++--
> > 5 files changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> > index 4375043..b91eec9 100644
> > --- a/include/net/bluetooth/bluetooth.h
> > +++ b/include/net/bluetooth/bluetooth.h
> > @@ -94,6 +94,12 @@ typedef struct {
> > #define BDADDR_ANY (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
> > #define BDADDR_LOCAL (&(bdaddr_t) {{0, 0, 0, 0xff, 0xff, 0xff}})
> >
> > +enum {
> > + BDADDR_TYPE_BR = 0,
>
> As we going to differentiate this, can't we separate BR and BR/EDR?
> Or maybe not once most of the device today should be BR/EDR.
what is the difference between BR and BR/EDR exactly? I don't see one
and in general the specification calls this BR/EDR. So using BREDR seems
more correct.
> > + BDADDR_TYPE_LE_PUBLIC,
> > + BRADDR_TYPE_LE_RANDOM
> > +};
I am also not sure the we should have this BR/EDR differentiation since
the specification only talks about public and random addresses. And we
should follow the specification type value here. I am against
introducing our enum here.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 2/2] Bluetooth: Add support for returning the encryption key size
From: Marcel Holtmann @ 2011-04-16 5:24 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth, johan.hedberg
In-Reply-To: <1302915440.2503.26.camel@aeonflux>
Hi Vinicius,
> And of course the same now applies for PIN code length. Even if with
> Simple Pairing this does not matter anymore. For Legacy Pairing this is
> still relevant.
forget about this comment. It is actually bogus since the HIGH vs MEDIUM
security for Legacy Pairing implies the PIN length requirement already.
We just need to make sure to enforce it properly via the new in-kernel
handling of pairing.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] Proposal to distinguish address device types
From: Johan Hedberg @ 2011-04-16 7:00 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo F. Padovan, Claudio Takahasi, linux-bluetooth
In-Reply-To: <1302915790.2503.31.camel@aeonflux>
Hi Marcel,
On Fri, Apr 15, 2011, Marcel Holtmann wrote:
> > > + BDADDR_TYPE_LE_PUBLIC,
> > > + BRADDR_TYPE_LE_RANDOM
> > > +};
>
> I am also not sure the we should have this BR/EDR differentiation since
> the specification only talks about public and random addresses. And we
> should follow the specification type value here. I am against
> introducing our enum here.
The HCI specification only has values for public and random because
everywhere they are used it is already clear from the context (the HCI
command or event in question) if we're talking about LE or BR/EDR. We on
the other hand don't have this contextual information with the
mgmt_pair_device command. Saying "public" there could mean both BR/EDR
public or LE public, i.e. an enum with just two possible values is not
going to be of much use to us. Because of this difference between our
API and that of HCI I don't think it's fair to apply the HCI
convention/restriction to us.
Johan
^ permalink raw reply
* [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Gottfried Haider @ 2011-04-16 16:38 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-bluetooth
Hello,
I am having problems pairing bluetooth devices in 2.6.39. Scanning
works fine (hcitool scan), but when I try to pair a device using
"bluez-simple-agent hci0 $MAC", I receive the following error message:
"Creating device failed: org.bluez.Error.Failed: Input/output error"
The same command reliably works on a 2.6.38.3 kernel with pretty much
the same config.
According to lsusb, I have a Broadcom Bluetooth Controller with ID
0a5c:217f. I don't see anything related in either of the dmesgs.
My lspci output is here: http://sukzessiv.net/x120e/
Userspace is an up-to-date Ubuntu 11.04 beta (with bluez 4.91).
If there are any debugging steps that I could do or patches to try or
revert, let me know. Unfortunately I can't do a proper bisect since
the machine is a netbook type.
cheers,
gohai
^ permalink raw reply
* Re: [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Justin P. Mattock @ 2011-04-16 17:01 UTC (permalink / raw)
To: Gottfried Haider; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <BANLkTi=LvyZ+7BHfVL849pztfvsYaVM4SQ@mail.gmail.com>
On 04/16/2011 09:38 AM, Gottfried Haider wrote:
> Hello,
>
> I am having problems pairing bluetooth devices in 2.6.39. Scanning
> works fine (hcitool scan), but when I try to pair a device using
> "bluez-simple-agent hci0 $MAC", I receive the following error message:
> "Creating device failed: org.bluez.Error.Failed: Input/output error"
>
> The same command reliably works on a 2.6.38.3 kernel with pretty much
> the same config.
>
> According to lsusb, I have a Broadcom Bluetooth Controller with ID
> 0a5c:217f. I don't see anything related in either of the dmesgs.
> My lspci output is here: http://sukzessiv.net/x120e/
> Userspace is an up-to-date Ubuntu 11.04 beta (with bluez 4.91).
>
> If there are any debugging steps that I could do or patches to try or
> revert, let me know. Unfortunately I can't do a proper bisect since
> the machine is a netbook type.
>
> cheers,
> gohai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I'm wondering if you are hitting what I was hitting a few days ago.. the
commit below got things working over here:
(not sure if this is in the stable yet)
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next-2.6.git;a=commitdiff;h=b99faf1b798d6d0e33526fd2cef55a405c08ff09;hp=58b6e124aac64bebb2e9e1a136cbd21a5ab0485a
hope this helps,
Justin P. Mattock
^ permalink raw reply
* Re: [RFC] Proposal to distinguish address device types
From: Claudio Takahasi @ 2011-04-16 17:04 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, Gustavo F. Padovan, Claudio Takahasi,
linux-bluetooth
In-Reply-To: <20110416070006.GA10860@jh-x301>
Hi Marcel,
On Sat, Apr 16, 2011 at 7:00 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Marcel,
>
> On Fri, Apr 15, 2011, Marcel Holtmann wrote:
>> > > + BDADDR_TYPE_LE_PUBLIC,
>> > > + BRADDR_TYPE_LE_RANDOM
>> > > +};
>>
>> I am also not sure the we should have this BR/EDR differentiation since
>> the specification only talks about public and random addresses. And we
>> should follow the specification type value here. I am against
>> introducing our enum here.
>
> The HCI specification only has values for public and random because
> everywhere they are used it is already clear from the context (the HCI
> command or event in question) if we're talking about LE or BR/EDR. We on
> the other hand don't have this contextual information with the
> mgmt_pair_device command. Saying "public" there could mean both BR/EDR
> public or LE public, i.e. an enum with just two possible values is not
> going to be of much use to us. Because of this difference between our
> API and that of HCI I don't think it's fair to apply the HCI
> convention/restriction to us.
>
> Johan
>
I added 3 values because it gives more flexibility. Possible use cases:
- Whitelist needs the address type
- SMP
- As input to decide to store or not information about the device
since private address can change every 15minutes
At the moment we only need to know if the address is basic rate or LE
to select the discovery type: SDP or LE Discovery primary. For
pairing, Vinicius is using the kernel advertising cache to discover
the address type, passing the address type could avoid wrong fallback
to basic rate if the entry is not found in the cache.
Claudio
^ permalink raw reply
* Re: [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Gottfried Haider @ 2011-04-16 22:43 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <4DA9CB83.4050000@gmail.com>
Hi Justin,
> I'm wondering if you are hitting what I was hitting a few days ago.. the
> commit below got things working over here:
> (not sure if this is in the stable yet)
> http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next-2.6.git;a=commitdiff;h=b99faf1b798d6d0e33526fd2cef55a405c08ff09;hp=58b6e124aac64bebb2e9e1a136cbd21a5ab0485a
I checked: I have this commit in -rc3, so it must be something else here.
greetings,
gohai
^ permalink raw reply
* Re: [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Justin P. Mattock @ 2011-04-16 23:35 UTC (permalink / raw)
To: Gottfried Haider; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <BANLkTi=avo9yvpQ0VRPRv1uroF3ZnJzfAg@mail.gmail.com>
On 04/16/2011 03:43 PM, Gottfried Haider wrote:
> Hi Justin,
>
>> I'm wondering if you are hitting what I was hitting a few days ago.. the
>> commit below got things working over here:
>> (not sure if this is in the stable yet)
>> http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next-2.6.git;a=commitdiff;h=b99faf1b798d6d0e33526fd2cef55a405c08ff09;hp=58b6e124aac64bebb2e9e1a136cbd21a5ab0485a
>
> I checked: I have this commit in -rc3, so it must be something else here.
>
> greetings,
>
> gohai
>
hmm... seems to be working over here with the latest Mainline. one thing
I have notice though is the daemon is not starting during
boot(systemd), manually starting bluetoothd gets me to connect.(system
is fedora 15).
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] bluetooth: fix shutdown on SCO sockets
From: Luiz Augusto von Dentz @ 2011-04-17 17:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20110415185845.GB2359@joana>
Hi Gustavo,
On Fri, Apr 15, 2011 at 9:58 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Luiz,
>
> * Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-04-08 17:10:41 +0300]:
>
>> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>>
>> shutdown should wait for SCO link to be properly disconnected before
>> detroying the socket, otherwise an application using the socket may
>> assume link is properly disconnected before it really happens which
>> can be a problem when e.g synchronizing profile switch.
>>
>> Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> I applied it, but in bluetooth-next. Let's see its behaviour there and if no
> problems show up we can move it to bluetooth-2.6
I tested this against Nokia BH-504 and Sony Ericsson W600, both have
problem when switching from hfp to a2dp where the avdtp start is sent
before SCO is fully disconnected, this patch fixes with those
headsets.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Wrong timeout when connecting to device with removed pairing
From: Luiz Augusto von Dentz @ 2011-04-17 17:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20110415192858.GD2359@joana>
Hi,
On Fri, Apr 15, 2011 at 10:28 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> * Gustavo F. Padovan <padovan@profusion.mobi> [2011-04-15 16:22:58 -0300]:
>
>> Hi Luiz,
>>
>> * Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-04-12 14:36:01 +0300]:
>>
>> > Apparently this is a regression caused by commit
>> > 769be974d0c7b4fe1a52f9cdaad22259b60953f7 - [Bluetooth] Use ACL config
>> > stage to retrieve remote features, when receiving pincode request in a
>> > new connection the state will be BT_CONFIG so HCI_PAIRING_TIMEOUT is
>> > never set to the connection, this could be reproduced by removing a
>> > link key in the remote side and trying to connect:
>> >
>> > 2011-04-05 12:11:37.070953 < HCI Command: Authentication Requested
>> > (0x01|0x0011) plen 2
>> > handle 1
>> > 2011-04-05 12:11:37.071686 > HCI Event: Command Status (0x0f) plen 4
>> > Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
>> > 2011-04-05 12:11:37.071838 > HCI Event: Link Key Request (0x17) plen 6
>> > bdaddr 00:1F:E1:EB:B9:CB
>> > 2011-04-05 12:11:37.075073 < HCI Command: Link Key Request Reply
>> > (0x01|0x000b) plen 22
>> > bdaddr 00:1F:E1:EB:B9:CB key 92BA9EAD06542B0600457C609B8F5395
>> > 2011-04-05 12:11:37.075775 > HCI Event: Command Complete (0x0e) plen 10
>> > Link Key Request Reply (0x01|0x000b) ncmd 1
>> > status 0x00 bdaddr 00:1F:E1:EB:B9:CB
>> > 2011-04-05 12:11:37.087005 > HCI Event: PIN Code Request (0x16) plen 6
>> > bdaddr 00:1F:E1:EB:B9:CB
>> > 2011-04-05 12:11:39.038849 < ACL data: handle 1 flags 0x00 dlen 12
>> > L2CAP(s): Disconn req: dcid 0x00a9 scid 0x0040
>> > 2011-04-05 12:11:39.100647 > HCI Event: Number of Completed Packets
>> > (0x13) plen 5
>> > handle 1 packets 1
>> > 2011-04-05 12:11:39.100830 > ACL data: handle 1 flags 0x02 dlen 12
>> > L2CAP(s): Disconn rsp: dcid 0x00a9 scid 0x0040
>> > 2011-04-05 12:11:40.433624 > HCI Event: Auth Complete (0x06) plen 3
>> > status 0x13 handle 1
>> > Error: Remote User Terminated Connection
>> > 2011-04-05 12:11:40.437774 > HCI Event: Disconn Complete (0x05) plen 4
>> > status 0x00 handle 1 reason 0x13
>> > Reason: Remote User Terminated Connection
>> >
>> > I think the following patch might fix it:
>> >
>> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> > index 3fbfa50..abdc4de 100644
>> > --- a/net/bluetooth/hci_event.c
>> > +++ b/net/bluetooth/hci_event.c
>> > @@ -1973,10 +1973,14 @@ static inline void hci_pin_code_request_evt(struct
>> > hci_dev *hdev, struct sk_buff
>> > hci_dev_lock(hdev);
>> >
>> > conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
>> > - if (conn && conn->state == BT_CONNECTED) {
>> > - hci_conn_hold(conn);
>> > + if (conn) {
>> > conn->disc_timeout = HCI_PAIRING_TIMEOUT;
>> > - hci_conn_put(conn);
>> > +
>> > + /* Update disconnect timer */
>> > + if (conn->state == BT_CONNECTED) {
>> > + hci_conn_hold(conn);
>> > + hci_conn_put(conn);
>>
>> I think these two line can be:
>>
>> mod_timer(&conn->disc_timer, jiffies + HCI_PAIRING_TIMEOUT);
>>
>>
>> The two main difference are that here we don't delete the idle_timer, but it
>> isn't used anywhere, so I think we can delete it.
>
> My mistake, idle_timer is actually used, I forgot to look hci_conn.c
Well apparently the patch didn't really help to fix the problem, any
other ideas?
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Maciej Rutecki @ 2011-04-17 18:40 UTC (permalink / raw)
To: Gottfried Haider; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <BANLkTi=LvyZ+7BHfVL849pztfvsYaVM4SQ@mail.gmail.com>
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=33482
for your bug report, please add your address to the CC list in there, thanks!
On sobota, 16 kwietnia 2011 o 18:38:59 Gottfried Haider wrote:
> Hello,
>
> I am having problems pairing bluetooth devices in 2.6.39. Scanning
> works fine (hcitool scan), but when I try to pair a device using
> "bluez-simple-agent hci0 $MAC", I receive the following error message:
> "Creating device failed: org.bluez.Error.Failed: Input/output error"
>
> The same command reliably works on a 2.6.38.3 kernel with pretty much
> the same config.
>
> According to lsusb, I have a Broadcom Bluetooth Controller with ID
> 0a5c:217f. I don't see anything related in either of the dmesgs.
> My lspci output is here: http://sukzessiv.net/x120e/
> Userspace is an up-to-date Ubuntu 11.04 beta (with bluez 4.91).
>
> If there are any debugging steps that I could do or patches to try or
> revert, let me know. Unfortunately I can't do a proper bisect since
> the machine is a netbook type.
>
> cheers,
> gohai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* [PATCH 1/2] Add NO CARRIER response to HFP
From: Dmitriy Paliy @ 2011-04-17 21:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
HFP is updated by NO CARRIER response accordingly to HFP 1.5 p.68.
---
audio/headset.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/audio/headset.c b/audio/headset.c
index c605e9d..2e4f6ca 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -687,14 +687,17 @@ static int telephony_generic_rsp(struct audio_device *device, cme_error_t err)
struct headset *hs = device->headset;
struct headset_slc *slc = hs->slc;
- if (err != CME_ERROR_NONE) {
- if (slc->cme_enabled)
- return headset_send(hs, "\r\n+CME ERROR: %d\r\n", err);
- else
- return headset_send(hs, "\r\nERROR\r\n");
- }
+ if ((err != CME_ERROR_NONE) && slc->cme_enabled)
+ return headset_send(hs, "\r\n+CME ERROR: %d\r\n", err);
- return headset_send(hs, "\r\nOK\r\n");
+ switch (err) {
+ case CME_ERROR_NONE:
+ return headset_send(hs, "\r\nOK\r\n");
+ case CME_ERROR_NO_NETWORK_SERVICE:
+ return headset_send(hs, "\r\nNO CARRIER\r\n");
+ default:
+ return headset_send(hs, "\r\nERROR\r\n");
+ }
}
int telephony_event_reporting_rsp(void *telephony_device, cme_error_t err)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] Add NO CARRIER reponse to maemo6 telephony driver
From: Dmitriy Paliy @ 2011-04-17 21:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1303075754-15375-1-git-send-email-dmitriy.paliy@nokia.com>
---
audio/telephony-maemo6.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index be2fb87..b32e8ad 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -630,9 +630,14 @@ static void create_call_reply(DBusPendingCall *call, void *user_data)
if (dbus_set_error_from_message(&err, reply)) {
error("csd replied with an error: %s, %s",
err.name, err.message);
- dbus_error_free(&err);
- telephony_dial_number_rsp(telephony_device,
+ if (g_strcmp0(err.name,
+ "com.nokia.csd.Call.Error.CSInactive") == 0)
+ telephony_dial_number_rsp(telephony_device,
+ CME_ERROR_NO_NETWORK_SERVICE);
+ else
+ telephony_dial_number_rsp(telephony_device,
CME_ERROR_AG_FAILURE);
+ dbus_error_free(&err);
} else
telephony_dial_number_rsp(telephony_device, CME_ERROR_NONE);
--
1.7.1
^ permalink raw reply related
* [PATCH] Bluetooth: Only keeping SAR bits when retransmitting one frame.
From: Ruiyi Zhang @ 2011-04-18 3:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ruiyi Zhang
When retrasmitting one frame, only SAR bits in control field should
be kept.
Signed-off-by: Ruiyi Zhang <Ruiyi.zhang@atheros.com>
---
net/bluetooth/l2cap_core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index ca27f3a..2c8dd44 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1051,6 +1051,7 @@ static void l2cap_retransmit_one_frame(struct sock *sk, u8 tx_seq)
tx_skb = skb_clone(skb, GFP_ATOMIC);
bt_cb(skb)->retries++;
control = get_unaligned_le16(tx_skb->data + L2CAP_HDR_SIZE);
+ control &= L2CAP_CTRL_SAR;
if (pi->conn_state & L2CAP_CONN_SEND_FBIT) {
control |= L2CAP_CTRL_FINAL;
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix not waiting for POLLERR when disconnecting SCO
From: Luiz Augusto von Dentz @ 2011-04-18 6:57 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
To make sure the SCO link is really disconnected we should wait for
POLLERR since POLLHUP does not necessarily means the link is
completely disconnected just that no further data can be sent/received.
Note that this depend on a fix of SCO socket shutdown in kernel to wait
for disconnect confimation to then kill/destroy the socket indicating
the err/reason using POLLERR.
---
audio/headset.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/headset.c b/audio/headset.c
index c605e9d..819e0f8 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -2548,7 +2548,7 @@ void headset_set_state(struct audio_device *dev, headset_state_t state)
AUDIO_HEADSET_INTERFACE, "State",
DBUS_TYPE_STRING, &state_str);
hs->sco_id = g_io_add_watch(hs->sco,
- G_IO_ERR | G_IO_HUP | G_IO_NVAL,
+ G_IO_ERR | G_IO_NVAL,
(GIOFunc) sco_cb, dev);
g_dbus_emit_signal(dev->conn, dev->path,
--
1.7.1
^ permalink raw reply related
* Re: [Regression] Bluetooth pairing does not work anymore in 2.6.39-rc3 (works in 2.6.38.3)
From: Gottfried Haider @ 2011-04-18 7:34 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-bluetooth, padovan
In-Reply-To: <4DAA27C8.7060800@gmail.com>
>> I checked: I have this commit in -rc3, so it must be something else here.
> hmm... seems to be working over here with the latest Mainline. one thing I
> have notice though is the daemon is not starting during boot(systemd),
> manually starting bluetoothd gets me to connect.(system is fedora 15).
It was my fault after all:
I had based my kernel config on 2.6.39-rc2 from Ubuntu's
mainline-kernel PPA, and this doesn't have BT_L2CAP..
Case closed.
I am just wondering: is it possible to make BT_L2CAP (and SCO?)
default to yes when BT is compiled in or build as a module?
>From commit 6427451: "The L2CAP layer is needed by almost all
Bluetooth protocols and profiles. There isn't any real use case
without having L2CAP loaded." Yet when I am doing oldconfig from a
config that had L2CAP build as a module, I am getting these easily
overlooked lines:
L2CAP protocol support (BT_L2CAP) [N/y/?] (NEW)
SCO links support (BT_SCO) [N/y/?] (NEW)
cheers,
gohai
^ permalink raw reply
* Re: [PATCH 1/2] Add NO CARRIER response to HFP
From: Johan Hedberg @ 2011-04-18 7:50 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth, Dmitriy Paliy
In-Reply-To: <1303075754-15375-1-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Mon, Apr 18, 2011, Dmitriy Paliy wrote:
> HFP is updated by NO CARRIER response accordingly to HFP 1.5 p.68.
> ---
> audio/headset.c | 17 ++++++++++-------
> 1 files changed, 10 insertions(+), 7 deletions(-)
Both patches have been pushed upstream after I fixed your author email
(please fix your git config) and a minor coding style issue in the
second patch.
Johan
^ permalink raw reply
* Re: Endless print of uhci_result_common: failed with status 440000
From: Zdenek Kabelac @ 2011-04-18 10:54 UTC (permalink / raw)
To: Alan Stern, Zdenek Kabelac, USB list, Linux Kernel Mailing List,
linux-bluetooth, padovan
In-Reply-To: <20110412182618.GB2836@joana>
2011/4/12 Gustavo F. Padovan <padovan@profusion.mobi>:
> * Alan Stern <stern@rowland.harvard.edu> [2011-04-12 12:10:56 -0400]:
>
>> On Tue, 12 Apr 2011, Zdenek Kabelac wrote:
>>
>> > 2011/4/11 Alan Stern <stern@rowland.harvard.edu>:
>> > > On Mon, 11 Apr 2011, Zdenek Kabelac wrote:
>> > >
>> > >> > I've created:
>> > >> >
>> > >> > https://bugzilla.kernel.org/show_bug.cgi?id=33062
>> > >> >
>> > >> > and I'm cc-ing linux-bluetooth.
>> > >> >
>> > >>
>> > >> In fact this Ooops might be related to:
>> > >>
>> > >> http://marc.info/?l=linux-kernel&m=130207593728273&w=2
>> > >
>> > > It might be. ?Did you try reverting the patch mentioned in that email?
>> > >
>> >
>> > Yep - it looks like the patch
>> > http://marc.info/?l=linux-bluetooth&m=130230770920378&w=2
>> > solved my problem with weird deadlocks.
>
> I pushed a patch that fixes this in a better way, it's on the bluetooth-2.6
> tree (should arrive to linus tree in some days).
hmm
Ok - I assume you mean this patch:
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=commitdiff;h=b7d850641d2bc45b2320bfcb096f11406890ff3a
It seems to be detaching timer slightly differently as the one from
Keith probably.
Here is the trace I've got with older Keith's patch (which I've
believed was fine already)
iwl3945 0000:03:00.0: loaded firmware version 15.32.2.9
systemd[1]: Service bluetooth.target is not needed anymore. Stopping.
------------[ cut here ]------------
WARNING: at lib/list_debug.c:30 __list_add+0x8f/0xa0()
Hardware name: 6464CTO
list_add corruption. prev->next should be next (ffff88013b139390), but
was 2020203a6c61746f. (prev=ffff880137b63350).
Modules linked in: sunrpc ipt_REJECT xt_physdev xt_state
iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack nf_defrag_ipv4 ip_tables x_tables btusb bluetooth
snd_hda_codec_analog arc4 ecb crypto_blkcipher cryptomgr aead
crypto_algapi snd_hda_intel iwl3945 snd_hda_codec snd_seq iwl_legacy
snd_seq_device mac80211 snd_pcm thinkpad_acpi cfg80211 snd_timer
e1000e psmouse snd serio_raw wmi soundcore i2c_i801 snd_page_alloc
nvram iTCO_wdt iTCO_vendor_support evdev i915 dm_mirror dm_region_hash
dm_log dm_mod drm_kms_helper drm i2c_algo_bit i2c_core autofs4 usbhid
hid pcmcia sdhci_pci sdhci ehci_hcd uhci_hcd mmc_core sr_mod cdrom
yenta_socket usbcore video backlight
Pid: 44, comm: kworker/1:2 Not tainted 2.6.39-rc3-00236-g115ab9e #7
Call Trace:
[<ffffffff810501df>] warn_slowpath_common+0x7f/0xc0
[<ffffffff810502d6>] warn_slowpath_fmt+0x46/0x50
[<ffffffff812988ef>] __list_add+0x8f/0xa0
[<ffffffff810602f3>] internal_add_timer+0xb3/0x140
[<ffffffff81062bd2>] mod_timer+0x152/0x450
[<ffffffff81117bb6>] ? refresh_cpu_vm_stats+0x106/0x170
[<ffffffff81062ee8>] add_timer+0x18/0x20
[<ffffffff8106df4f>] queue_delayed_work_on+0xbf/0x140
[<ffffffff8106f0d1>] queue_delayed_work+0x21/0x40
[<ffffffff8106f10b>] schedule_delayed_work+0x1b/0x20
[<ffffffff81117c71>] vmstat_update+0x51/0x60
[<ffffffff81070c38>] process_one_work+0x1c8/0x6f0
[<ffffffff81070bd7>] ? process_one_work+0x167/0x6f0
[<ffffffff81493c44>] ? retint_restore_args+0xe/0xe
[<ffffffff81117c20>] ? refresh_cpu_vm_stats+0x170/0x170
[<ffffffff81071539>] worker_thread+0x159/0x340
[<ffffffff810713e0>] ? rescuer_thread+0x240/0x240
[<ffffffff810760fb>] kthread+0x9b/0xa0
[<ffffffff8149b9d4>] kernel_thread_helper+0x4/0x10
[<ffffffff810367a4>] ? finish_task_switch+0x74/0x110
[<ffffffff8149367b>] ? _raw_spin_unlock_irq+0x3b/0x60
[<ffffffff81493c44>] ? retint_restore_args+0xe/0xe
[<ffffffff81076060>] ? __init_kthread_worker+0x70/0x70
[<ffffffff8149b9d0>] ? gs_change+0xb/0xb
---[ end trace 9184dc8969677db3 ]---
I'll see whether new version will not show this warning.
Zdenek
^ permalink raw reply
* RE: [PATCH 3/3] Bluetooth: Ignore key unauthenticated for high security
From: Waldemar.Rymarkiewicz @ 2011-04-18 13:19 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz, linux-bluetooth; +Cc: johan.hedberg
In-Reply-To: <1302865617-32704-4-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi,
>Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
>---
> net/bluetooth/hci_event.c | 21 +++++++++++++++++----
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
>diff --git a/net/bluetooth/hci_event.c
>b/net/bluetooth/hci_event.c index 5c5e614..337da2b 100644
>--- a/net/bluetooth/hci_event.c
>+++ b/net/bluetooth/hci_event.c
>@@ -2044,11 +2044,24 @@ static inline void
>hci_link_key_request_evt(struct hci_dev *hdev, struct sk_buff
> }
>
> conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
>+ if (conn) {
>+ if (key->type == HCI_LK_UNAUTH_COMBINATION &&
>+ conn->auth_type != 0xff &&
>+ (conn->auth_type & 0x01)) {
>+ BT_DBG("%s ignoring unauthenticated
>key", hdev->name);
>+ goto not_found;
>+ }
>
>- if (key->type == HCI_LK_UNAUTH_COMBINATION && conn &&
>- conn->auth_type != 0xff &&
>(conn->auth_type & 0x01)) {
>- BT_DBG("%s ignoring unauthenticated key", hdev->name);
>- goto not_found;
>+ if (key->type == HCI_LK_COMBINATION &&
>+ conn->sec_level ==
>BT_SECURITY_HIGH &&
>+ conn->pin_length < 16) {
That's wrong. I should check it against stored key->pin_len and conn->pending_sec_level.
We are in the middle of authentication so we don't have conn->sec_level set properly yet. The same apply for conn->pin_length.
if (key->type == HCI_LK_COMBINATION && key->pin_len < 16 &&
conn->pending_sec_level == BT_SECURITY_HIGH) {
goto not_found;
}
/Waldek
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox