[Winpcap-users] Size of packet captured!
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
> 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
* 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
* 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
* specified by the packet type field of the NETLIB header
* field has the same value for all NETLIB packets that make up a TDS
* The "server response" PDU consists of a sequence of multiple
* 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
* 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
* Some more information can be found in
* Much of this code was originally developed for the FreeTDS project.
* 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
* data, typically to 512 or 4096 bytes. Between this are the
* 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