I have the same "TDS5 query[Mailformed Packet]" but when I look at the TDS packet, the decoded length for token 0x21 is 822083584(equivalent to hex 0x31000000) but the byte stream associated with it is 0x00000031. There are exactly 0x31 bytes of data followed the length field. I wonder that the TDS decoder mix up on the big/little endian in the interpretation. I run the wireshark on Windows(litte-endian) to analyze the packets while the packet captured were between two Solaris servers(big-endian). I assume that "[Mailformed Packet]" is spilled out by TDS decoder since it believe it should see 822083584 bytes of data after the length field but it only see 49 bytes(0x31). If this is on the right track, than the question is whether TDS decoder decodes incorrectly all the time or it could decode correctly if the packets captured on little-endian OS? If TDS decoder can decode correctly some time, is there information(endian related) in the packets to allow TDS decoder always decode correctly? -Frank asked 24 Nov '12, 08:58  frank converted to question 24 Nov '12, 09:46  Guy Harris ♦♦ |
One Answer:
The TDS decoder has a "TDS decode as" preference; it can be set to "Little Endian", which is the default (regardless of whether the machine on which Wireshark is running, or the machine on which the traffic is captured, is big-endian or little-endian), or to "Big Endian". You should set it to "Big Endian" if the traffic is, as appears to be the case, big-endian. The byte order of the host on which the capture was done, or on which Wireshark is running (which are not necessarily the same host), isn't relevant here. At least in some versions of the login messages, there's a byte-order indicator, which could be used to determine the byte order of the session, but currently isn't being used for that. That wouldn't, of course, help if the login wasn't captured. The dissector could also possibly check the sanity of the 4-byte length field for those tokens that have them, and switch the byte order if the high-order bits of the length field in the current byte order are set and the low-order bits are clear. answered 24 Nov '12, 10:15 Guy Harris ♦♦ |
