This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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's gravatar image

frank
1111
accept rate: 0%

converted to question 24 Nov '12, 09:46

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196


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.

permanent link

answered 24 Nov '12, 10:15

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×21
×10
×4

question asked: 24 Nov '12, 08:58

question was seen: 6,599 times

last updated: 24 Nov '12, 10:15

p​o​w​e​r​e​d by O​S​Q​A