From: Marcel Holtmann <marcel@holtmann.org>
To: jaikumar Ganesh <jaikumarg@gmail.com>
Cc: Nick Pelly <npelly@google.com>,
Ville Tervo <ville.tervo@nokia.com>,
linux-bluetooth@vger.kernel.org, johan.hedberg@nokia.com
Subject: Re: [RFC] Some kernel changes
Date: Wed, 28 Jan 2009 11:35:50 +0100 [thread overview]
Message-ID: <1233138950.2139.4.camel@violet> (raw)
In-Reply-To: <ac290f760901280218q3eefc51es5e3b500c629f6c68@mail.gmail.com>
Hi Jaikumar,
> >> >> >>>>> why do you wanna set AUTH_PENDING again. That is not needed we only
> >> >> >>>>> wanna know once encryption comes back on. If no in time, then we just
> >> >> >>>>> disconnect the link. That simple.
> >> >> >>>>>
> >> >> >>>>>> b) I also see that we are not clearing the timer and hence after
> >> >> >>>>>> RFCOMM_AUTH_TIMEOUT period expires we bring down the RFCOMM connection
> >> >> >>>>>> even though the encryption has been established.
> >> >> >>>>>
> >> >> >>>>> Good catch. Fixed it.
> >> >> >>>>
> >> >> >>>> Cool. Can you upload it to bluetooth-testing git ? I saw a related
> >> >> >>>> problem while looking at the timer issue and wanted to see if the fix
> >> >> >>>> takes care of it.
> >> >> >>>
> >> >> >>> I am in the process in doing so, but there are other important things
> >> >> >>> that need to be done first.
> >> >> >>
> >> >> >> Sorry to push you on this, is this patch been uploaded ?
> >> >> >
> >> >> > since a few days now. Check the bluetooth-testing.git and it is even rebased
> >> >> > against 2.6.29-rc2.
> >> >> >
> >> >> I applied the patches and I see that we actually don't pause the
> >> >> RFCOMM tx traffic because we don't check on
> >> >> the RFCOMM_SEC_PENDING flag when sending the tx packets in rfcomm_process_dlcs.
> >> >> I verified this using the "attest" command - we keep sending RFCOMM
> >> >> traffic even though encryption is off.
> >> >>
> >> >> Please look at the patch attached.
> >> >>
> >> >> Also should we drop the "rx" packets too when the encryption is dropped ?
> >> >
> >> > can you get me a version with a proper commit message. Just the subject
> >> > is not gonna be good enough.
> >> >
> >>
> >> Sorry, its attached. Also like mentioned above the patch checks only
> >> while sending tx packets ?
> >> Should we drop "rx" packets also ?
> >
> > patch looks fine to me, but you need to fix/revert the comment change ;)
> >
> > diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> > index ae2ecaa..73ffc0c 100644
> > --- a/net/bluetooth/rfcomm/core.c
> > +++ b/net/bluetooth/rfcomm/core.c
> > @@ -1,4 +1,4 @@
> > -/*
> > +f*
> > RFCOMM implementation for Linux Bluetooth stack (BlueZ).
> > Copyright (C) 2002 Maxim Krasnyansky <maxk@qualcomm.com>
> > Copyright (C) 2002 Marcel Holtmann <marcel@holtmann.org>
> >
> > And I like to have a little bit more detailed commit message please.
> >
> Sure I will resubmit
> Also, should we drop the "rx" packets ?
no, we can't do that since RFCOMM support to be a reliable stream.
Regards
Marcel
next prev parent reply other threads:[~2009-01-28 10:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-10 12:33 [RFC] Some kernel changes Ville Tervo
2009-01-10 14:18 ` Marcel Holtmann
2009-01-10 14:26 ` Johan Hedberg
2009-01-12 13:53 ` Marcel Holtmann
2009-01-12 17:15 ` Nick Pelly
2009-01-13 19:12 ` Marcel Holtmann
2009-01-15 19:13 ` jaikumar Ganesh
2009-01-15 23:25 ` Marcel Holtmann
2009-01-15 23:52 ` jaikumar Ganesh
2009-01-16 9:47 ` Marcel Holtmann
2009-01-20 18:54 ` jaikumar Ganesh
2009-01-20 20:02 ` Marcel Holtmann
2009-01-21 0:28 ` jaikumar Ganesh
2009-01-21 11:19 ` Marcel Holtmann
2009-01-21 17:46 ` jaikumar Ganesh
2009-01-28 9:27 ` jaikumar Ganesh
2009-01-28 9:59 ` Marcel Holtmann
2009-01-28 10:18 ` jaikumar Ganesh
2009-01-28 10:35 ` Marcel Holtmann [this message]
2009-01-15 19:14 ` jaikumar Ganesh
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=1233138950.2139.4.camel@violet \
--to=marcel@holtmann.org \
--cc=jaikumarg@gmail.com \
--cc=johan.hedberg@nokia.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=npelly@google.com \
--cc=ville.tervo@nokia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.