[Winpcap-users] Size of packet captured!

Guy Harris guy at alum.mit.edu
Fri Jul 24 09:44:35 PDT 2009

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.


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  
  * 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  
  * 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  
  * NETLIB packets with the last packet indicator clear and a final  
  * 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  
  * 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.   
  * items are fixed length, some are variable length with a two byte  
  * field following the item type, and then there is TDS_ROW_TOKEN in  
  * size is determined by analyzing the result set returned from the  
  * 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  
  * in the login packet.  We can attempt to determine it later on, but  
  * 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  
  * 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,  
  * netlib packets may appear in single real packets.  TDS PDUs may be  
  * 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.

More information about the Winpcap-users mailing list