> On Oct 29, 2003, at 5:20 PM, Igor Cananéa wrote:
>
> > Hi. I'm developing a protocol dissector for DNP version 3. It
> > implements a data link layer protocol over TCP/IP
>
> C00l! Could you give me the IP address of your local electrical power
> substation? Let me see if I can 0wnz0r it.... :-)
This is more likely than you would like to think ... The serial stuff is
also used a lot over unencrypted radio links.
>
> > (because it was initially used over serial lines) and an aplication
> > layer protocol. I've finished the data link layer dissector but I'm
> > having trouble with the ap layer. The dll divides the ap messages in
> > 252 byte packets. I need to reassemble them in the ap dissector so the
> > data can make any sense. How can I do that?
>
> There's a fairly general (but not yet documented) set of routines in
> the "reassemble.c" file in the top-level source directory; there are
> several types of fragmentation, so there are several types of
> reassembly supported by it.
>
> How is the fragmentation done? In particular, presumably there's
> something in either the data link layer or the application layer that
> has some indication that a packet is fragmented, and some way of
> indicating which fragment of a fragmented packet a particular data link
> layer is; how is that done? Given that, we might be able to indicate
> what sort of reassembly needs to be done (and to indicate what other
> dissector does similar reassembly), or discover that we need to support
> another form of reassembly and add that to reassemble.c.
I've also been working on a DNP3 dissector and am also stuck on the
reassembly of the app layer.
There are actually three layers:
The data link layer - this carries a payload of 0 - 250 bytes of data, the
data consists of 16 octet blocks each followed by a 2 octet CRC. The last
block may have less than 16 octets of data. There is a 10 octet header
containing a start sequence constant, the length of the user data, the
source and destination addresses and a 2 octet CRC.
The transport layer - this carries a payload of (potentially) infinite size.
There is a 1 octet header at the start of each data link layer payload
containing two flag bits indicating the first and last frames of a sequence,
and a 6 bit sequence number that increments for each successive frame. Any
sequence number is valid for the first frame of a sequence.
The application layer - this carries a payload of (potentially) infinite
size. There is a 2 or 4 octet header (depending on whether the message is a
request or a response) that contains two flag bits indicating the first and
last frames of a sequence, and a 6 bit sequence number that increases for
each successive frame. The sequence numbers 0 - 15 are for requests and
responses, and numbers 16 - 31 are for unsolicited responses from the
outstations.
So given this, my dissector reads in a data link frame and strips out the
payload checking the CRC on each block. A new tvb is created for this
stripped data minus the transport header octet. The contents of the tvb are
added to a reassembly table using fragment_add_seq_check(), but I never get
a value back to indicate that reassembly is complete.
Regards,
Graham Bloice
