["Abhik Sarkar" <sarkar.abhik@xxxxxxxxx>]

Another example:
P1 = packet-smpp
P2 = packet-gsm_sms_ud

On 7/14/07, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Jul 13, 2007, at 1:09 PM, Jon Andersen wrote:
>
> > I'm working on a protocol dissector for several layered protocols on
> > top of TCP and have a general dissection issue for which I'd like
> > some advice or wizardry.
> >
> > I have a packeted connection protocol on top of TCP, which itself
> > contains packets of another protocol:
> > TCP
> > P1
> > P2
> >
> > The issue is that the packets of P2 may be split up into multiple
> > packets of P1, and P1 may be split up into multiple packets by TCP.
> > This makes the reassembly and dissection tricky (-;
> >
> > tcp_dissect_pdus() works beautifully for handling fragmented P1
> > packets.  However, it doesn't help with the recursive problem of P2
> > packets being fragmented.
>
> It's not supposed to.  The information about the fragmentation of P2
> packets into multiple P1 packets is either known to the P1 dissector
> (see, for example, IP fragmentation) or the P2 dissector.
>
> Thus, either the P1 dissector should be handling the reassembly, or
> the P2 dissector should be handling the reassembly, possibly with the
> help of the P1 dissector.
>
> There's no master general reassembly mechanism in Wireshark, because
> there's no single scheme used by all protocols for fragmentation.
> There are helper routines in epan/reassemble.c for dissectors to use,
> and the reassembly code in a particular dissector might consist only
> of a few calls to those helper routines, which do the vast majority of
> the work - but different dissectors need to call different routines,
> as their protocols do fragmentation differently.
>
> tcp_dissect_pdus() is only a small part of the TCP reassembly
> mechanism; it's just a wrapper for certain types of protocols, but
> other protocols, such as HTTP, do the reassembly differently, as HTTP
> requests and responses don't have a message length in a header near
> the beginning of the message (the HTTP header is terminated by a blank
> line, so you have to keep grabbing data until you find the blank line;
> the HTTP body might have its length specified by the Content-Length
> field of the header, or it might run until the connection closes).
>
> The TCP reassembly mechanism is, by design and intent designed to
> handle only the reassembly of messages that cross TCP segment
> boundaries.  It involves both the TCP dissector and the dissector
> above it, as the service TCP provides is a byte stream, with no
> message boundaries, so only the dissector above TCP knows what the
> message boundaries are.  tcp_dissect_pdus() is a wrapper that
>
>         1) handles multiple messages in a single segment
>
> and
>
>         2) handles the details of telling the TCP dissector that more data is
> needed for messages that cross segment boundaries.
>
> Burdening the TCP reassembly mechanism with handling reassembly for
> other protocols would complicate that code - and it's already
> complicated, and has some known bugs that need to be fixed.
>
> > Think about what happens when a P2 packet is split across two P1
> > packets, and each of the P1 packets is encapsulated in a different
> > TCP packet.
>
> Think about what happens when a TDS packet is split across multiple
> NETLIB packets.  See packet-tds.c for an example of a set of protocols
> that work the way your P1 and P2 protocols work.
>
> >   What is needed is a fancier or more general implementation of
> > tcp_dissect_pdus, updated to handle new-style dissectors.
>
> No, what is needed is dissectors for P1 and P2 that do the reassembly
> of P2 packets fragmented over multiple P1 packets.  Again, see packet-
> tds.c.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev