Ethereal-dev: Re: [Ethereal-dev] How to access value of hdr.frag_len from subdissector?

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

From: "Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>
Date: Mon, 17 Jun 2002 07:33:11 +1000
"Guy Harris"  wrote
> On Sun, Jun 16, 2002 at 12:28:48PM -0700, Jaime Fournier wrote:
> > I need to know hdr.frag_num.
> > I only want to print certain info when the it's the
> > initial packet, and not a following frag.
>
> What do following fragments contain?
>
> I.e., would your dissector be able to do anything other than report
> "this isn't the first fragment" for following fragments?
>
> I suspect that this means that the real way to handle this is to fix the
> DCE RPC dissector to reassemble fragments and/or call the subdissector
> only for the first fragment (probably based on a "do reassembly"
> preference setting, as is the case with other dissectors that do
> reassembly).

The DCE RPC dissector already supports fragment reassembly for connection
oriented
DCERPC.
Make sure that both options in
Edit/Preferences/Protocols/DCERPC/
are activated.
Also make sure that Edit/Preferences/Protocols/TCP/Allow-subdiss... is
enabled.

If your DCERPC sessions runs over SMB, then you should also make sure that
the following
options are enabled :
Edit/Preferences/Protocols/NBSS/Desegment...
Edit/Preferences/Protocols/SMB/Reassemble SMB Transaction payload
Edit/Preferences/Protocols/SMB/Reassemble DCERPC over SMB


Now you have enough options enabled which will eat memory like there is no
tomorrow,
but it will desegment and reassemble ALL DCERPC (connection oriented)
packets for you.
The actual DCERPC subdissector, such as EPM will ONLY be called once, for
the LAST packet
which completes the reassembly of the PDU.
Just do some cut-n-paste in packet-dcerpc.c if you need reassembly for
connection-less DCERPC as well.

(as for eating memory, each layer of reassembly unfortunately needs its own
malloced local copy of all the data.
If, as is common for DCERPC over SMB,  you ahve PDUs which are reassembled
in NBSS+SMB+DCERPC
layers, this means that ehtereal needs 3x more memory to do reassembly than
the size of the capture file.)