From: Marcel Holtmann <marcel@holtmann.org>
To: Mat Martineau <mathewm@codeaurora.org>
Cc: "Gustavo F. Padovan" <gustavo@padovan.org>,
linux-bluetooth@vger.kernel.org, rshaffer@codeaurora.org
Subject: Re: [PATCH 1/8] Bluetooth: Make sure the L2CAP FCS is only enabled for ERTM or streaming.
Date: Tue, 03 Aug 2010 09:50:55 -0700 [thread overview]
Message-ID: <1280854255.12579.96.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.2.00.1008030918360.19861@linux-sea-02>
Hi Mat,
> >>>>>>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> >>>>>>> ---
> >>>>>>> net/bluetooth/l2cap.c | 12 ++++++++----
> >>>>>>> 1 files changed, 8 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> >>>>>>> index 9ba1e8e..aed72f2 100644
> >>>>>>> --- a/net/bluetooth/l2cap.c
> >>>>>>> +++ b/net/bluetooth/l2cap.c
> >>>>>>> @@ -3127,8 +3127,10 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> >>>>>>> goto unlock;
> >>>>>>>
> >>>>>>> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> >>>>>>> - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> >>>>>>> - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
> >>>>>>> + if ((l2cap_pi(sk)->mode == L2CAP_MODE_ERTM ||
> >>>>>>> + l2cap_pi(sk)->mode == L2CAP_MODE_STREAMING) &&
> >>>>>>> + (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> >>>>>>> + l2cap_pi(sk)->fcs != L2CAP_FCS_NONE))
> >>>>>>> l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
> >>>>>>
> >>>>>> this becomes unreadable and my brain starts to throw a core dump. So it
> >>>>>> clearly needs to be put into a helper inline function.
> >>>>>
> >>>>> Actually we don't need that, since the code that deals with Basic Mode
> >>>>> never check and use the l2cap_pi(sk)->fcs. So we don't care about FCS
> >>>>> value in the Basic Mode.
> >>>>
> >>>> There isn't currently any Basic Mode code that triggers this latent
> >>>> bug, but I have a patch coming up that does require this fix.
> >>>>
> >>>> As it stands, getsockopt() on a connected basic mode socket shows FCS
> >>>> enabled, so this bug is visible from userspace.
> >>>
> >>> can we just fail the setsockopt() when trying to set basic mode and FCS
> >>> off.
> >>
> >> It definitely makes sense to have more validation of L2CAP_OPTIONS
> >> passed to setsockopt().
> >>
> >>> And also in case fallback to basic mode happens, then FCS should be set
> >>> to be enabled. Since for FCS and basic mode we always have to use FCS.
> >>> So that seems just fine to me.
> >>
> >> The spec says "The FCS option shall only be used when the mode is
> >> being, or is already configured to Enhanced Retransmission mode or
> >> Streaming mode." FCS is never used in basic mode (fallback or not).
> >>
> >> (Maybe I've misunderstood your point)
> >
> > So basic mode uses CRC16 as FCS. And with basic that is not changeable.
> > If you try basic mode + no FCS then we should clearly fail the call to
> > setsockopt() for that.
>
> That's the opposite of what I'm trying to say! :)
>
> Basic mode B-frames have *no* FCS (L2CAP spec section 3.1). The FCS
> field is only found in I-frames and S-frames used in ERTM and
> streaming modes. If you try basic mode + FCS, that should fail.
I confused myself right now. You are fully correct. The default for
basic mode is no fcs.
And as soon as an application wants to use ERTM we just make it to
specific the FCS option. That being CRC16 or no FCS. And of course the
getsockopt() call will return whatever we ended up configuring.
And yes, basic mode + crc16 should fail.
> >>> Maybe you need to explain a bit more in detail what you are trying to
> >>> achieve in conjunction with userspace API.
> >>
> >> My goal is to only have l2cap_pi(sk)->fcs == L2CAP_FCS_CRC16 when the
> >> FCS option is actually in use. Otherwise, any logic checking for FCS
> >> also has to check the L2CAP mode. Might as well check the mode once
> >> and set fcs accordingly -- which is what my patch does.
> >>
> >> Gustavo is correct that l2cap_pi(sk)->fcs is currently only checked on
> >> code paths used with ERTM and streaming mode. However, future code
> >> (including a patch I'll be posting soon) will depend on the fcs value
> >> being accurate in all modes.
> >
> > As I said, I have no problem with returning basic mode + crc16. Since
> > that is actually what you are doing in that case.
> >
> > The only thing that we have to keep in mind to be backward compatible is
> > to allow setting of basic mode and fcs = 0x00 and then change that into
> > crc16.
>
> The fcs field in L2CAP_OPTIONS is new for ERTM/Streaming modes, so
> there should be no backward compatibility issues with basic mode.
There is none. I got confused. Too many emails at the same time.
Regards
Marcel
next prev parent reply other threads:[~2010-08-03 16:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 19:20 [PATCH 0/8] Bluetooth: L2CAP updates for PSM validation and ERTM Mat Martineau
2010-08-02 19:20 ` [PATCH 1/8] Bluetooth: Make sure the L2CAP FCS is only enabled for ERTM or streaming Mat Martineau
2010-08-02 19:38 ` Marcel Holtmann
2010-08-02 21:20 ` Gustavo F. Padovan
2010-08-02 22:40 ` Mat Martineau
2010-08-02 22:51 ` Marcel Holtmann
2010-08-03 15:58 ` Mat Martineau
2010-08-03 16:11 ` Marcel Holtmann
2010-08-03 16:23 ` Mat Martineau
2010-08-03 16:50 ` Marcel Holtmann [this message]
2010-08-03 18:44 ` Gustavo F. Padovan
2010-08-02 19:20 ` [PATCH 2/8] Bluetooth: Change default ERTM retransmit timeout to 2 seconds, as the spec requires Mat Martineau
2010-08-02 19:40 ` Marcel Holtmann
2010-08-02 19:20 ` [PATCH 3/8] Bluetooth: Validate PSM values in calls to connect() and bind() Mat Martineau
2010-08-02 19:39 ` Marcel Holtmann
2010-08-02 21:24 ` Gustavo F. Padovan
2010-08-02 19:20 ` [PATCH 4/8] Bluetooth: Do endianness conversion on MPS configuration value before doing comparisons Mat Martineau
2010-08-02 19:41 ` Marcel Holtmann
2010-08-02 19:20 ` [PATCH 5/8] Bluetooth: Don't modify remote_tx_win when receiving a config response. Only config requests should set remote_tx_win Mat Martineau
2010-08-02 19:42 ` Marcel Holtmann
2010-08-02 19:20 ` [PATCH 6/8] Bluetooth: Move stream-oriented recvmsg code so it can be used by L2CAP Mat Martineau
2010-08-02 19:46 ` Marcel Holtmann
2010-08-02 22:13 ` Mat Martineau
2010-08-02 19:20 ` [PATCH 7/8] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets Mat Martineau
2010-08-02 19:53 ` Marcel Holtmann
2010-08-02 19:20 ` [PATCH 8/8] Bluetooth: Use 3-DH5 payload size for default ERTM max PDU size Mat Martineau
2010-08-02 19:48 ` Marcel Holtmann
2010-08-03 16:13 ` Mat Martineau
2010-08-02 19:50 ` [PATCH 0/8] Bluetooth: L2CAP updates for PSM validation and ERTM Marcel Holtmann
2010-08-02 22:02 ` Mat Martineau
2010-08-02 22:09 ` Marcel Holtmann
2010-08-02 23:56 ` ERTM known bugs/regressions (was Re: [PATCH 0/8] ...) Mat Martineau
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=1280854255.12579.96.camel@localhost.localdomain \
--to=marcel@holtmann.org \
--cc=gustavo@padovan.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=mathewm@codeaurora.org \
--cc=rshaffer@codeaurora.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 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.