On Friday, August 22, 2003, at 2:48 PM, Tom Jordan wrote:
Attached is a capture of a TDS stream that I had posted to the list.
Note to self: next time, if I put in a comment saying "do XXX and then
return", don't forget to put the "return;" statement in.
I.e., the problem is that there's a bug in Ethereal (which I put in),
so don't trust what it displays to reflect reality.
I've attached a patch that puts the missing "return;" statement into
the TDS dissector, so that it correctly dissects Netlib messages that
cross TCP segment boundaries, like the ones in your capture. It also
makes an attempt to dissect part of the "remote procedure call" packets
(there appears to be a counted string at the beginning; I don't know
what's in the rest of the packet), and cleans up some other stuff.
If you've built Ethereal from source, or can do so, apply the patch to
"packet-tds.c" and rebuild. If you can't build Ethereal from source,
wait for the next release, which will have that fix, as I checked it
into the Ethereal CVS source code base.
Having fixed that:
I went through the items you suggested. The packets of interest are
packets 10 &
11, 13 & 14, and 15 & 16.
Packets 10, 11, and 13 reassemble into a Netlib packet, but that isn't
a complete TDS response; packet 14 contains another Netlib packet, and
if you combine those two Netlib packets, you get the complete TDS
response. They display in a way that might make it look as if there
are two TDS responses, but there's really only one.
Packet 15 is just an ACK. If you turn on the "Analyze TCP sequence
numbers" preference for TCP from the Preferences dialog box (Edit >
Preferences menu item; open up "Protocols" in that dialog box, select
TCP, turn on the option, and click "OK"), you'll get a "SEQ/ACK
analysis" item that says that it's acking stuff in frame 14.
Packet 16 is a request (a "remote procedure call" packet).
The only TCP retransmission (shown if you turn on "Analyze TCP sequence
numbers") is frame 26.