Wireshark · Ethereal-dev: Re: [Ethereal-dev] subpacket question

[Guy Harris <guy@xxxxxxxxxx>]

On Tue, Apr 16, 2002 at 08:18:30AM -0400, Brian Bruns wrote:
> I'm finely getting back to working on the TDS dissector.  I have the 
> netlib dissector handling multiple netlib packet per physical packet and 
> partial netlib packets in a physical packet.  Now the problem (warning! 
> bad ascii art to follow):
> 
> tcp                 netlib          tds
> +----------+   +-------------+   +----------+ 
> |          |   |             |   | TDS PDU 1|   
> |          |   | netlib      |   +----------+
> |  tcp     |   | packet 1    |   |          |
> | packet   |   |             |   | TDS PDU 2|
> |          |   +-------------+   |          |
> |          |   |             |   +----------+
> |          |   | netlib      |   |          |
> |          +---+ packet 2    +---+ TDS PDU 3|
> |          |   |             |   |          |
> |          |   +-------------+   |          |
> |          |   |             |   +----------+
> |          |   | netlib      |   | TDS PDU 4|
> |          |   | packet 2    |   +----------+
> |          |   | (partial)   |   | TDS PDU 5|
> |          |   |             |   | (partial)|
> +----------+   +-------------+   +----------+
> 
> so the outer tcp packet can contain any number (of parts) of netlib 
> packets, and in turn each netlib packet contains parts, one, several TDS 
> protocol data units.

The diagram appears to show the netlib boundaries as not necessarily
being aligned with TDS boundaries, i.e. it looks as if TDS PDU 2 is made
from stuff in netlib packets 1 and 2,  TDS PDU 3 is made from stuff in
netlib packets 2 and "2 (partial)".  (Is the third netlib packet in the
TCP segment really netlib packet 3?)

Is that the case?  Or is it more like:

tcp                 netlib          tds
+----------+   +-------------+   +----------+ 
|          |   |             |   | TDS PDU 1|   
|          |   | netlib      |   +----------+
|  tcp     |   | packet 1    |   |          |
| packet   |   |             |   | TDS PDU 2|
|          |   +-------------+   +----------+
|          |   |             |   |          |
|          |   | netlib      |   |          |
|          +---+ packet 2    +---+ TDS PDU 3|
|          |   |             |   |          |
|          |   +-------------+   +----------+
|          |   |             |   |          |
|          |   | netlib      |   | TDS PDU 4|
|          |   | packet 3    |   +----------+
|          |   | (partial)   |   | TDS PDU 5|
|          |   |             |   | (partial)|
+----------+   +-------------+   +----------+

with TDS PDUs not being split between netlib PDUs (and with the third
netlib packet labeled as "netlib packet 3 (partial)"?

> With netlib I stuff some data in the protocol info during the first run 
> through the packets and that allows me to know where in the next packet 
> the thing is supposed to end.

For netlib, this looks as if what you really want is to do TCP
reassembly, along the lines of what, say, the NetBIOS-over-TCP Session
Service dissector, "dissect_nbss()", in "packet-nbns.c", does.

That would not only handle multiple netlib packets per TCP segment, it
would also handle netlib packets split *across* TCP segments - and would
eliminate the need to store the information in the protocol info
yourself; the information stored by the TCP reassembly code would do
that for you.

> With TDS however I get several get several calls to the dissector with 
> different offsets.  I need a way to store data from the previous 
> invocation (and then possibly accessed out of order) about the part of the 
> TDS PDU that came in the last netlib packet.

If TDS PDUs are never split across netlib packet boundaries, this
shouldn't be an issue - the netlib dissector would, if netlib reassembly
is enabled, handle only complete netlib packets, so it could just loop
through the reassembled packet and show all the TDS PDUs in it.

if they *are* split across netlib packet boundaries, you'd need
to do your own reassembly of TDS PDUs; that might be able to use some of
the existing support infrastructure for reassembly.