On Thursday, August 7, 2003, at 10:40 AM, Tom Jordan wrote:
Not being an expert in TDS packet decodes I would appreciate some
help. I have captured a sql client - server conversation of TDS
packets that appears to have quite a few retransmissions from the
server to the client. The first odd frame is a TDS Response Packet
from the server to the client that ethereal says is a Short Frame.
Then the server sends the same packet again which is marked as an
Unreassembled Packet.
Is it the *same* packet (with the same TCP sequence number), or are
they separate packets in the TCP data stream?
The client sends a TCP ACK. Then the server sends another TDS
Unreassembled Packet followed by an identical packet marked as a TDS
Response Packet.
Or, rather, the server sends a packet that Ethereal reports as an
unreassembled packet.
Any TDS packet that requires more than one TCP segment will be reported
as an unreassembled packet if Ethereal hasn't reassembled it from the
TCP segments that compose it; by default, it will attempt to do that,
but there may be reasons why it didn't do so.
One reason might be that you've turned those options off; select
Preferences from the Edit menu, open up the list of protocols in the
dialog box that pops up, and select "TDS" and make sure both options
are turned on.
Another reason might be that the full contents of the packet weren't
captured, which is usually reported as a "Short Frame". In the packet
reported as a Short Frame, check the "Frame" line in the protocol tree
pane (middle pane) - if the "bytes captured" value is less than the
"bytes on wire" value, that's what happened, and you need to capture
the full packet (don't use "Limit each packet to {N} bytes" in
Ethereal, don't use the "-s" option in Tethereal, *do* use the "-s"
option in tcpdump/WinDump and give either 65535 or, in newer versions
of tcpdump/WinDump, 0 as the argument to "-s").
If neither of those are the case, we'd probably have to see the raw
binary capture file to diagnose this.