From: Marcel Holtmann <marcel@holtmann.org>
To: "Gustavo F. Padovan" <padovan@profusion.mobi>
Cc: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>,
linux-bluetooth@vger.kernel.org
Subject: Re: [bluetooth-next 10/15] Bluetooth: Add support for resuming socket when SMP is finished
Date: Fri, 08 Apr 2011 09:34:08 -0700 [thread overview]
Message-ID: <1302280448.2572.200.camel@aeonflux> (raw)
In-Reply-To: <20110407001100.GE2228@joana>
Hi Gustavo,
> > This adds support for resuming the user space traffic when SMP
> > negotiation is complete.
> >
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> > ---
> > net/bluetooth/l2cap_core.c | 61 ++++++++++++++++++++++---------------------
> > net/bluetooth/l2cap_sock.c | 16 +++++++++++
> > net/bluetooth/smp.c | 40 ++++++++++++++++++++--------
> > 3 files changed, 75 insertions(+), 42 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 0cec292..a5062f14 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -665,6 +665,22 @@ clean:
> > bh_unlock_sock(parent);
> > }
> >
> > +static void l2cap_chan_ready(struct sock *sk)
> > +{
> > + struct sock *parent = bt_sk(sk)->parent;
> > +
> > + BT_DBG("sk %p, parent %p", sk, parent);
> > +
> > + l2cap_pi(sk)->conf_state = 0;
> > + l2cap_sock_clear_timer(sk);
> > +
> > + sk->sk_state = BT_CONNECTED;
> > + sk->sk_state_change(sk);
> > +
> > + if (parent)
> > + parent->sk_data_ready(parent, 0);
> > +}
> > +
> > static void l2cap_conn_ready(struct l2cap_conn *conn)
> > {
> > struct l2cap_chan_list *l = &conn->chan_list;
> > @@ -680,15 +696,11 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
> > for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
> > bh_lock_sock(sk);
> >
> > - if (conn->hcon->type == LE_LINK) {
> > - l2cap_sock_clear_timer(sk);
> > - sk->sk_state = BT_CONNECTED;
> > - sk->sk_state_change(sk);
> > + if (l2cap_pi(sk)->scid == L2CAP_CID_LE_DATA) {
> > if (smp_conn_security(conn, l2cap_pi(sk)->sec_level))
> > - BT_DBG("Insufficient security");
> > - }
> > + l2cap_chan_ready(sk);
> >
> > - if (sk->sk_type != SOCK_SEQPACKET &&
> > + } else if (sk->sk_type != SOCK_SEQPACKET &&
> > sk->sk_type != SOCK_STREAM) {
> > l2cap_sock_clear_timer(sk);
> > sk->sk_state = BT_CONNECTED;
> > @@ -1362,29 +1374,6 @@ int l2cap_sar_segment_sdu(struct sock *sk, struct msghdr *msg, size_t len)
> > return size;
> > }
> >
> > -static void l2cap_chan_ready(struct sock *sk)
> > -{
> > - struct sock *parent = bt_sk(sk)->parent;
> > -
> > - BT_DBG("sk %p, parent %p", sk, parent);
> > -
> > - l2cap_pi(sk)->conf_state = 0;
> > - l2cap_sock_clear_timer(sk);
> > -
> > - if (!parent) {
> > - /* Outgoing channel.
> > - * Wake up socket sleeping on connect.
> > - */
> > - sk->sk_state = BT_CONNECTED;
> > - sk->sk_state_change(sk);
> > - } else {
> > - /* Incoming channel.
> > - * Wake up socket sleeping on accept.
> > - */
> > - parent->sk_data_ready(parent, 0);
> > - }
> > -}
> > -
> > /* Copy frame to all raw sockets on that connection */
> > static void l2cap_raw_recv(struct l2cap_conn *conn, struct sk_buff *skb)
> > {
> > @@ -3810,6 +3799,18 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
> > for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
> > bh_lock_sock(sk);
> >
> > + BT_DBG("sk->scid %d", l2cap_pi(sk)->scid);
> > +
> > + if (l2cap_pi(sk)->scid == L2CAP_CID_LE_DATA) {
> > + if (!status && encrypt) {
> > + l2cap_pi(sk)->sec_level = hcon->sec_level;
> > + l2cap_chan_ready(sk);
> > + }
> > +
> > + bh_unlock_sock(sk);
> > + continue;
> > + }
> > +
> > if (l2cap_pi(sk)->conf_state & L2CAP_CONF_CONNECT_PEND) {
> > bh_unlock_sock(sk);
> > continue;
> > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> > index f77308e..14e491a 100644
> > --- a/net/bluetooth/l2cap_sock.c
> > +++ b/net/bluetooth/l2cap_sock.c
> > @@ -29,6 +29,7 @@
> > #include <net/bluetooth/bluetooth.h>
> > #include <net/bluetooth/hci_core.h>
> > #include <net/bluetooth/l2cap.h>
> > +#include <net/bluetooth/smp.h>
> >
> > /* ---- L2CAP timers ---- */
> > static void l2cap_sock_timeout(unsigned long arg)
> > @@ -614,6 +615,7 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
> > {
> > struct sock *sk = sock->sk;
> > struct bt_security sec;
> > + struct l2cap_conn *conn;
> > int len, err = 0;
> > u32 opt;
> >
> > @@ -650,6 +652,20 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname, ch
> > }
> >
> > l2cap_pi(sk)->sec_level = sec.level;
> > +
> > + conn = l2cap_pi(sk)->conn;
> > + if (conn && l2cap_pi(sk)->scid == L2CAP_CID_LE_DATA) {
> > + if (!conn->hcon->out) {
> > + err = -EINVAL;
> > + break;
> > + }
> > +
> > + if (smp_conn_security(conn, sec.level))
> > + break;
> > +
> > + err = 0;
> > + sk->sk_state = BT_CONFIG;
> > + }
>
> I don't like the idea of bring SMP stuff to l2cap_sock.c, we are working now
> to clean up that file and keep only socket related stuff there, and only
> channel related stuff in l2cap_core.c. I've already sent a patchset on that
> direction to mailing list. However, I don't have any idea now on how to remove
> smp_conn_security() from here.
I don't think we have much choice here. We could abstract this out with
drivers, but in the end we want direct functions call and not some heavy
abstracted framework. Since lets face it, this is all pretty static.
However we might need some better function naming for this. Some of the
naming inside L2CAP is a bit odd and not really clear what it does.
Regards
Marcel
next prev parent reply other threads:[~2011-04-08 16:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 1:51 [bluetooth-next 00/15] SM Just Works Implementation Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 01/15] Bluetooth: Implement the first SMP commands Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 02/15] Bluetooth: Start SMP procedure Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 03/15] Bluetooth: simple SMP pairing negotiation Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 05/15] Bluetooth: LE SMP Cryptoolbox functions Vinicius Costa Gomes
2011-04-06 23:26 ` Gustavo F. Padovan
2011-04-06 1:51 ` [bluetooth-next 06/15] Bluetooth: Add SMP confirmation structs Vinicius Costa Gomes
2011-04-06 23:36 ` Gustavo F. Padovan
2011-04-08 21:55 ` Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 07/15] Bluetooth: Add SMP confirmation checks methods Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 08/15] Bluetooth: Minor fix in SMP methods Vinicius Costa Gomes
2011-04-06 19:09 ` Gustavo F. Padovan
2011-04-06 1:51 ` [bluetooth-next 09/15] Bluetooth: Add support for LE Start Encryption Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 10/15] Bluetooth: Add support for resuming socket when SMP is finished Vinicius Costa Gomes
2011-04-07 0:11 ` Gustavo F. Padovan
2011-04-07 14:48 ` Vinicius Costa Gomes
2011-04-08 16:34 ` Marcel Holtmann [this message]
2011-04-06 1:51 ` [bluetooth-next 11/15] Bluetooth: Fix initial security level of LE links Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 12/15] Bluetooth: Update the security level when link is encrypted Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 13/15] Bluetooth: Add support for Pairing features exchange Vinicius Costa Gomes
2011-04-06 19:18 ` Gustavo F. Padovan
2011-04-06 1:51 ` [bluetooth-next 14/15] Bluetooth: Add support for SMP timeout Vinicius Costa Gomes
2011-04-07 0:14 ` Gustavo F. Padovan
2011-04-07 0:32 ` Vinicius Costa Gomes
2011-04-06 1:51 ` [bluetooth-next 15/15] Bluetooth: Add key size checks for SMP Vinicius Costa Gomes
-- strict thread matches above, loose matches on Subject: below --
2011-02-21 17:23 [bluetooth-next 00/15] SMP Just Works Implementation Vinicius Costa Gomes
2011-02-21 17:23 ` [bluetooth-next 10/15] Bluetooth: Add support for resuming socket when SMP is finished Vinicius Costa Gomes
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=1302280448.2572.200.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=padovan@profusion.mobi \
--cc=vinicius.gomes@openbossa.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).