linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Aring <aring@mojatatu.com>
To: Rafael Vuijk <r.vuijk@sownet.nl>
Cc: Alexander Aring <alex.aring@gmail.com>,
	Jukka Rissanen <jukka.rissanen@linux.intel.com>,
	linux-wpan@vger.kernel.org, linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] ieee802154: assembly of 6LoWPAN fragments improvement
Date: Wed, 18 Jul 2018 10:30:15 -0400	[thread overview]
Message-ID: <20180718143015.y32gl5sesuwwb2ux@x220t> (raw)
In-Reply-To: <20180717152620.GB22664@Rafael-Mac.intra.sownet.nl>

Hi,

On Tue, Jul 17, 2018 at 05:26:20PM +0200, Rafael Vuijk wrote:
> 6LoWPAN reassembly fragment overlap checks.
> 
> Signed-off-by: Rafael Vuijk <r.vuijk@sownet.nl>
> --- ./net/ieee802154/6lowpan/reassembly.c	2018-02-20 11:10:06.000000000 +0100
> +++ ./net/ieee802154/6lowpan/reassembly.c	2018-02-21 09:13:29.000000000 +0100
> @@ -179,6 +170,13 @@ static int lowpan_frag_queue(struct lowp
>  	}
>  
>  found:
> +	/* Current fragment overlaps with previous fragment? */
> +	if (prev && (lowpan_802154_cb(prev)->d_offset << 3) + prev->len > offset)
> +		goto err;
> +	/* Current fragment overlaps with next fragment? */
> +	if (next && offset + skb->len > lowpan_802154_cb(next)->d_offset << 3)
> +		goto err;
> +

I have some thought of mine when seeing this code. The function is
separated into two phases:

phase 0:
 - finding the missing piece of fragment skb in the right order
 - if found goto found:

phase 1:
 - everything after found to reassemble everything if we have everything
   together.


This patch moves parts which are belongs to "phase 0" to "phase 1". I
think the general idea in this algorithmn is to simple don't make checks
on invalid things at all. If "broken" fragments are inside the "fragment
bucket" then simple leave it there. There exists a garbage collector,
controlled by some expire parameter to drop them then (60 seconds by
default).

Important is that the code should never run lowpan_frag_reasm() when
something is not right in the fragments.

- Alex

  reply	other threads:[~2018-07-18 14:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 15:26 [PATCH 2/2 v2] ieee802154: assembly of 6LoWPAN fragments improvement Rafael Vuijk
2018-07-18 14:30 ` Alexander Aring [this message]
2018-07-24 13:08   ` Stefan Schmidt
2018-07-24 13:04 ` Stefan Schmidt

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=20180718143015.y32gl5sesuwwb2ux@x220t \
    --to=aring@mojatatu.com \
    --cc=alex.aring@gmail.com \
    --cc=jukka.rissanen@linux.intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=r.vuijk@sownet.nl \
    /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).