This will work for a fixed length PDU, which does seem to be Peter's
situation, or a PDU with a length value in the start of the PDU.
Though I found to documentation in README.developer to be somewhat
confusing. A simpler example that handles only TCP data may help here.
In my situation I don't know the PDU length because it contains null
terminated strings. I wanted to decode the entire PDU so I return a
pinfo->desegment_offset of zero with pinfo->desegment_len = tvb_len()+1.
As I stated before, in the email 'TCP reassembly and desegment_offset = 0'
I never see a second call to the sub_dissector by the TCP desegment code.
I have traced this to ipfd_head value of zero returned by fragment_add
in the packet-tcp.c code. Digging into the reassemble.c code it seems to
me that the problem is caused by my dissector requesting less data then
is available in the next packet (fragment).
Jeff F>
> From: Ronnie Sahlberg
> Sent: Wednesday, September 01, 2004 4:14 AM
>
> Ethereal can do almost all of this for you hiding the ugly details of
> the pinfo->desegment_offset et all from you.
> The desegmentation API is tcp_dissect_pdus() in packet-tcp.c
>
> Do a grep for tcp_dissect_pdus in the epan/dissector directory to find
> multiple examples on how to use this api.
>
> It is very very easy to use.
>
>
> In addition to this, it will also, if desegmentation is NOT enabled
> still keep track of PDU boundaries so that IF a PDU starts somewhere
> in the middle of a segment, ethereal will still know this and where
> the next PDU starts.
>
>
>
> remember to enable BOTH the tcp preference as well as your own
> preference for your protocol to enable desegmentation.
>
>
> On Tue, 31 Aug 2004 16:26:35 -0500, Jeff Foster wrote:
> >
> > > I have a dissector that is added to handle tcp.port == 14000 which works
> > > well until segmented PDUs are received.
> > > I read section 2.7 "Reassembly/desegmentation" in the README.developer
> > > but cannot seem to get it work the way I want.
> >
> > <text deleted/>
> >
> > > If the data_length was 3 in the first call to the dissector I return
> > > that I want 1 additional byte from offset 3 in the next received tvb.
> > > This is probably where I have misunderstood something. The next tvb I
> > > receive contains the additional bytes that I requested, but only those.
> > > Hence the 3 bytes received the first time are now lost.
> > > I thought that I should be able to handle the PDU in its entirety. What >
> > > am I missing?
> >
> > The pinfo->desegment_offset value is where the next data segment should start.
> > So the desegment code will skip over the number of bytes indicated in the offset
> > and give the number of bytes in the length.
> >
> > If you want those three bytes on the next call you will have to set the offset
> > to the beginning of the three byte location.
> >
> > This is exactly what I ran into, I wanted to decode the entire PDU in one go so
> > I set the desegment_offset to 0 and set the desegment_len to tvb_len + 1.
> >
> > Jeff F>
> >
***
The information in this e-mail is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this e-mail in error, please notify the sender by return e-mail, delete this e-mail, and refrain from any disclosure or action based on the information.
***
