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

Hello all,

We have been having some serious performance problems from one of our applications. One of the suspects is the communication between our apps server and our SQL server. So I got a wireshark capture between the two and there is red everywhere, but I don't know what I'm looking at. I'm not a network guy, but I am digging to see if I can help fix this problem.

I checked the 'Expert Infos' and it has several errors:

Checksum IPv4 Bad Checksum 26027 Molformed TDS Malformed Packet(Exception occurred) 763 Checksum Ethernet Bad checksum 1400

This is a 30 second capture. Can I get some advice on whether this is bad and, if so, where should I look for the problem?

Thank you.

asked 12 Jun '13, 12:50

rwigs's gravatar image

rwigs
11112
accept rate: 0%


It depends on where you captured - if you did the capture on one of the devices that are part of the problem you probably "created" the CRC errors by the way you recorded the packets. But you also said you captured "between the two" which would usually mean that you had a third, passive device doing the capture, in which case the CRC errors would be a bad thing.

You can probably ignore the TDS messages, since this one just means that the TDS dissector in Wireshark had problems dissecting the payload. This is not a network error, it's a decoding problem.

permanent link

answered 12 Jun '13, 12:56

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

The capture was run on the APPS server, but I did uncheck 'Validate the TCP checksum if possible" option (I read that can cause these errors). There is also:

1 Warning: Acknowledgement number: Broken TCP. The acknowledge field is nonzero

12 Notes: "Time To Live" != 255 for a packet sent to the Local Network Control Block 1 No bind info for interface Context ID:0 375 Keep-Alive 131 Keep-Alive ACK 131 Retransmission(suspected) 11 Duplicate ACK(#1) 5 Duplicate ACK(#2) 2 Duplicate ACK(#3) 1 Fast Retransmission(suspected) 1 Duplicate ACK(#4) 1 Duplicate ACK(#5) 1 Duplicate ACK(#6) 1

6 Chats: Connection finish(FIN) 25 Connection reset(RST) 3 Connection establish request(SYS):server port microsoft-ds 1 Connection establish acknowledge(SYN+ACK)server port microsoft-ds 1 Connection establish request(SYS):server port netbios-ssn 1 Connection establish acknowledge(SYN+ACK)server port netbios-ssn 1

Does any of this provide more information?

(12 Jun '13, 13:34) rwigs

"Validate the TCP checksum if possible" is a display setting, not a recording setting, so it will tell Wireshark to not mark bad CRCs in the display, but it will still record bad CRCs when capturing.

The Time to live message is interesting but in most cases it is just a device not following RFC completely. It would require more investigation, especially into the source it is coming from.

The Keep alives are usually irrelevant, while Duplicate ACKs and Retransmissions can hint towards connection problems, but still need more investigation. For that a look into the capture file is necessary, because just reading the expert messages is not nearly providing enough details.

Forget the chats.

(12 Jun '13, 13:54) Jasper ♦♦
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:

×20

question asked: 12 Jun '13, 12:50

question was seen: 3,553 times

last updated: 12 Jun '13, 13:54

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