[Winpcap-users] Size of packet captured!

[Guy Harris]

On Jul 24, 2009, at 8:08 AM, Gianluca Varenni wrote:

> Actually, from what he said, the TDS protocol (which I don't know at  
> all)
> runs on top of TCP, so you need to use some sort of TCP flow  
> reassembly to
> know which 2 (or whatever other number of) packets to join.

Yes.

Wireshark dissects TDS, and it uses its TCP packet reassembly  
mechanism for this.

To quote the comment in the TDS dissector for Wireshark:

/*
  * The NETLIB protocol is a small blocking protocol designed to allow  
TDS
  * to be placed within different transports (TCP, DECNet, IPX/SPX).  A
  * NETLIB packet starts with an eight byte header containing:
  *
  *	a one-byte packet type field;
  *
  *	a one-byte status field;
  *
  *	a two-byte big-endian size field giving the size of the packet,
  *	including the header;
  *
  *	a two-byte big-endian channel number, used when multiple sessions
  *	are being multiplexed on a single connection;
  *
  *	a one-byte packet number, giving "the frame number of a multiplexed
  *	message, modulo 256";
  *
  *	a one-byte window, which is the number of frames to be sent
  *	before an acknowledgment message is received.
  *
  * followed by payload whose size is the value in the size field minus
  * 8.
  *
  * Microsoft Network Monitor 2.x dissects the 4 byte field (and  
indicates
  * that the one-byte last packet indicator also contains other bits).
  *
  * The TDS protocol consists of a number of protocol data units  
(PDUs) that
  * appear to be assembled from NETLIB packets, in the form of zero or  
more
  * NETLIB packets with the last packet indicator clear and a final  
NETLIB
  * packet with the last packet indicator set.  The type of the TDS  
PDU is
  * specified by the packet type field of the NETLIB header  
(presumably that
  * field has the same value for all NETLIB packets that make up a TDS  
PDU).
  *
  * The "server response" PDU consists of a sequence of multiple  
items, each
  * one beginning with a one byte type field at the start of the PDU.   
Some
  * items are fixed length, some are variable length with a two byte  
size
  * field following the item type, and then there is TDS_ROW_TOKEN in  
which
  * size is determined by analyzing the result set returned from the  
server.
  * This in effect means that we are hopelessly lost if we haven't  
seen the
  * result set.  Also, TDS 4/5 is byte order negotiable, which is  
specified
  * in the login packet.  We can attempt to determine it later on, but  
not
  * with 100% accuracy.
  *
  * Some preliminary documentation on the packet format can be found at
  * http://www.freetds.org/tds.html
  *
  * Some more information can be found in
  * http://download.nai.com/products/media/sniffer/support/sdos/sybase.pdf
  *
  * Much of this code was originally developed for the FreeTDS project.
  * http://www.freetds.org
  */

/*
  * Excerpts from Brian's posting to wireshark-dev:
  *
  * The TDS Protocol is actually a protocol within a protocol.  On the  
outside
  * there is netlib which is not so much a encapsulation as a blocking  
of the
  * data, typically to 512 or 4096 bytes.  Between this are the  
protocol data
  * units for TDS.  Netlib packets may be split over real packets,  
multiple
  * netlib packets may appear in single real packets.  TDS PDUs may be  
split
  * over netlib packets (and real packets) and most certainly can appear
  * multiple times within a netlib packet.

	...

So you might have to do *two layers* of reassembly.