["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

This is actually something I am looking at implementing very shortly.

Basically,  NFS/SMB and as seen in the mail, other services based on TCP
need this too,
really needs a way to keep track of PDU boundaries.

Basically, if the first first herader of a PDU in a tcp segment is not
aligned to the
start of the segment, the only way for ethereal to decode this PDU is to
have TCP desegmentation enabled.

TCP desegmentation does not work if there are missing packets. Also it eats
a lot of memory.


What I think would be a reasonably clean way to solve this would be to
1,   rename pinfo->desegment_len  which is currently only used by dissectors
to tell how many more bytes
it needs to be reassembled to get the full PDU   to
pinfo->bytes_until_next_pdu_starts.
Extend this value to both act as reporting how much more data we need for
reassembly and also as information to where the next PDU starts.  (trivial)
2,  currently, a subdissector, like ONCRPC, DCEPRC, NBSS, BGP, ... only sets
this field
IFF desegmentation of that protocol is enabled and if the transport offers
desegmentation.
Change the dissectors to ALWAYS set this value if the PDU continues beyond
this segment.  (semi-trivial)
3,  change the tcp dissector to keep a list for each conversation of the
sequence number the the next PDU
would start. In this list keep only the last 20 entries (should be enough to
handle retransmissions and such, and small so it would be easy to scan.)
4,   for each conversation, use a hash table to keep track of the mapping
between frame_id and offset into teh tvb in the tcp dissector.
In this table, ONLY store the entries where there the first PDU is not
aligned to the segment start. Assuming that this will not be the common case
this would likely keep the total hash table small.
5,   only examine for these conditions and populate these tables when we
scan/dissect the packet the first time (so we dont have to pay the runtime
cost when we apply filters and refilters the packetlist)
6,   Since we assume this case is reasonably uncommon,   IF calling the
dissectors reported that no
suitable subdissectors were found,   check if this frame is registered in
teh list from item #4 and if found,
try the subdissectors again using the stored offset. If this also fails,
decode as data.


Since i think this will not be the common case, i think the runtime cost
will be reasonably small. I also think that normally the tables will also
contain few entries and thus not consume much memory.
If these assumptions are correct, i would like to see this behaviour as
always on and not controlled by a
preference setting (since most users do not know that there are preferences,
and this would be a very useful enahncement).
On the other hand it WILL consume both additional cpu and memory at runtime
which is why i think it would
be bad to have as always on or enabled by default.

Comments? I think it would be good to have as always on feature assuming
that it will not really use much
memory or cpu in the common case. Still i dont like to add it as always on
since it will have runtime costs.

----- Original Message -----
From: "Guy Harris"
To: "konghw"
Sent: Tuesday, April 15, 2003 1:41 PM
Subject: [Ethereal-dev] Re: TCP retransmission in BGP dissector


> (Redirected to ethereal-dev, as this is ultimately a development
> question.)
>
> On Tue, Apr 15, 2003 at 11:08:21AM +0800, konghw wrote:
> >      Currently I am using Ethereal to capture and dissect BGP
> > messages.  It works well for most of the times.  However, I noticed that
> > when the BGP message header is over the edge of TCP segment, the BGP
> > dissector will meet some problem.  I have reported the bug and patch to
> > Guy Harris.  After checking in this patch, Ethereal BGP dissector works
> > well when there is no TCP segment loss and retransmission.
> >
>
> >      However, when there is TCP segment loss and retransmission, I
> > found BGP dissector didnt take the retransmission into consideration.
> > Once one segment is lost and the following several TCP segment
> > (depending on the length of the BGP message) may not be decoded
> > correctly even though the retransmission of the lost segment are
> > captured correctly.  I think TCP layer has solved the problem of segment
> > loss and retransmission.  I don't know whether Ethereal's BGP dissector
> > can be configured to handle the problem of segment loss and
> > retransmission correctly.  If not, are there any plan of adding this
> > feature to the BGP dissector of Ethereal?
>
> There probably shouldn't be any plans to do that, because...
>
> > I think this is not a problem only pertaining to BGP dissector.
> > All other dissectors for the protocols based on TCP will have the
> > similar problem.
>
> ...you're right - this *isn't* a problem unique to BGP, so it shouldn't
> be solved in the BGP dissector, it should be solved in the *TCP*
> dissector; as you said:
>
> I think TCP layer has solved the problem of segment loss and
> retransmission.
>
> > Adding the handling of TCP segment loss and retransmission in ethereal
> > will be very helpful to the analysis of these protocols.
>
> Yes.
>
> The code that currently does TCP sequence number analysis might be the
> code that should handle retransmissions; if it detects retransmitted
> data, and the original data is in the capture (which might always be the
> case if it can detect a retransmission), it should arrange that
> subdissectors of the TCP dissector not be called with the retransmitted
> data.
>
> That would mean that you'd have to have TCP sequence number analysis
> enabled in order to get retransmissions handled; in order to handle
> retransmissions, Ethereal would probably have to have a data structure
> for each TCP connection it sees, but that means that if you read in a
> capture of a SYN flood, and create a data structure for each SYN, you
> might run out of memory (that problem was, as I remember, seen in
> tcpdump, which allocates a data structure for each TCP connection by
> default, in order to support relative sequence numbers), so you want to
> have *some* option to control whether to handle retransmissions.
>
> It should also perhaps handle out-of-order data; that might best be
> handled in the reassembly code.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>