Ethereal-dev: Re: [Ethereal-dev] [PATCH] fid tracking

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

From: Tim Potter <tpot@xxxxxxxxx>
Date: Mon, 19 Nov 2001 10:49:34 +1100
On Sun, Nov 18, 2001 at 03:20:43PM +1100, Ronnie Sahlberg wrote:

> I assume you know that ethereal already can desegment NBSS packets, that is
> simply done by
> enabling TCP desegmentation and NBSS desegmentation in preferences.
> (NBSS desegmentation is ON by default, but TCP desegmentation must b
> enabled)
> Thisd gives you ~2-3kb PDUs when they hit the SMB layer.
> Better than nothing.

I didn't know that - neat!

> I look into reassembly of Transaction (responses) as well. But there are a
> few things I need to think through first.
> To start with, only the responses to Transaction calls can be fragmented
> (since requests does not have the
> data/parameter displacement field, only responses have that one).
> (Any idea of what Transaction[2] Secondary looks like and if it actually
> exists in normal captures?)

OK this is where it gets complicated.  Small DCERPC requests and responses
(under 5620 bytes I think) are sent using a single SMBtrans.  For larger
requests and responses the DCERPC packet is fragmented and the fragments
are sent using SMBreadX or SMBwritex.  The only way to link these together
is by the FID which is the same in the SMB{read,write}X packets as it is
in the SMBtrans packets.  I guess if you see the packets out of order then
you have to do some tricky stuff in your defragmenter but that's OK.

[...]

> If you could send me a capture or two with MSRPC PDUs spanning multiple SMB
> Transaction
> calls it would be a great help)

OK - I'll send you something but it's pretty easy to capture them yourself.
Just run usermanager or something between two NT machines and you'll
have lots of data to play with.

[...]

> Only the data area needs defragmentation. When the data area is completely
> defragmented, should if be supplied to PIPE/MSRPC
> dissectors for each packet holding a fragment or would it be enough only to
> call PIPE/SMPRC for
> the packet containing the first fragment?

I think the best idea is to present a completely assembled packet to
the dissector.

> Tim, I see you post from +1100. Canberra I assume.
> If you get past Sydney, gimme a yell and well have an ehtereal meeting over
> a barbeque and a crate of VB.

Yep - I'm in Canberra.  Next time I'm in Sydney maybe we can meet up.  A
whole crate between us?  That would be a challenge.  (-:


Tim.