Ethereal-dev: Re: [Ethereal-dev] can_desegment and smb transaction patch

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2001 20:34:12 +1100
Hi,
Yes it can.
The change is so small it I will not generate a separate patch for it.
In the reassembly routine, change the if-statement at the end from
if((pos==0) ...
to
if((!more_frags) ...

And it will display it for the last packet instead.
However, when dissecting the last fragment, we dont have the setup bytes
but this should be OK since we remember all important stuff from the setup
area
from when the first fragment was (partially) dissected.

---
Though, this means that we will see each PDU twice,
once for the first fragment which will dissect (the partial PDU) whatever is
seen in
the first fragment and will show [malformed frame] (which should be changed
to [short frame]) in COL_INFO
and once more for the last fragment where the entire reassembled PDU will be
displayed.


best regards
    ronnie sahlberg



----- Original Message -----
From: "Guy Harris"
To: "Pia Sahlberg"
Sent: Thursday, November 29, 2001 6:52 PM
Subject: Re: [Ethereal-dev] can_desegment and smb transaction patch


> On Wed, Nov 28, 2001 at 12:38:53PM +0000, Pia Sahlberg wrote:
> > 2, changes fragment reassembly of transaction smb to only show the
> > defragmented packet for the transaction smb holding the first fragment.
> > To see why, test it with a transaction SMB containing a ~60kb PDU or
larger.
> > The old behaviour had approximately quadratic behaviour regarding
> > runtime for dissecting such PDUs.
> > (example: NetShareEnum is a command which can grow really really large
if
> > the number of shares and comments are large)
>
> Could it be done in the SMB holding the last fragment instead?
>
> That would mean that
>
> 1) it'd work in Tethereal
>
> and
>
> 2) the dissection of a frame would change less between the first
>    pass and subsequent passes in Ethereal, so it'd be more
>    likely to get the Info column right.
>
> (The fact that the IPv4/IPv6/CLNP fragment reassembly, and the TCP
> segment reassembly, attach the reassembled data to the last frame makes
> both of those be true for them.)
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev