TCP ACKed lost segment

Question

Hi Guys,

I'm quite new to wireshark but i am using it to try and diagnose an issue with have with slow connectivity to our web site. I am see a lot of the following lines in the capture and wondered if anyone could help explain what they are:

[TCP ACKed lost segment] 55312 > http [ACK] Seq=1833164 Ack=9463120 Win=131072 Len=0
[TCP ACKed lost segment] 55253 > http [ACK] Seq=13802249 Ack=65723974 Win=512 Len=0
[TCP Segment of a reassembled PDU]
HTTP/1.1 100 Continue
[TCP Segment of a reassembled PDU]

Any ideas? I'm a little concerned about the lost segments should i be?

Regards

Andi

Answer 1

The TCP ACKed lost segment means that Wireshark missed at least one packet in the other direction. The receiving IP stack would not have ack'd unless it received it. So I'd check my placement of Wireshark and make sure that it is in the path for both directions. If so, is it on the one of the endpoints? The reason I ask is that sometimes TCP Chimney has to be disabled.

Answer 2

You often see "ACKed lost segment" when your capture dropped packets due to performance reasons, meaning that is was there and was received by the target (resulting in the ACK), but Wireshark didn't capture it. It happens a lot on very active links, in my experiency usually with throughput above 300Mbit/s. Other reasons can be an asymmetric routing table which has a different path for the ACKed packet than the ACK packed.

Answer 3

0

Hi, sorry to jump in on this thread, but I have a client with a Server 2008 machine that is having these lost segments show up in great quantity in our captures, they're also having difficulty with their main database program which is what prompted the captures in the first place.

Hope you can help, we've replaced NICS, Cables, switches and Router, and still the issue persists.

answered 04 May '11, 05:29

stsanford
1
accept rate: 0%

Do you see retransmissions for the lost segments? If not, you're probably experiencing drops like I pointed out before. Can you point out what the "difficulties" with the database are?

(04 May '11, 05:45) Jasper ♦♦

Will have to connect in again and re-examine the captures, but the database question I can answer. They're using a flat-file database that I think was built on delphi, so the database is .DAT and .IDX files. They are getting errors reported from the software that file already in use, file not found, resource record not found. It looks on first blush that it would be a problem with file permissions, but it's everyone has full control to the database at this point.

Support for the software only has the recommendation to reload the server (currently Server 2008 R2) as a Server 2003 server, as their testing doesn't yet certify the 2008 product line. I'd really like to avoid that pain if at all possible as you can imagine... Thanks for your speedy response Jasper, really appreciate the help.

(04 May '11, 06:21) stsanford

I guess you're experiencing SMB file locking trouble then, you should look for "LOCK NOT GRANTED" messages and similar SMB based errors. Tell the programmers to use a TCP port based database instead of a flat file DB, those usually suck in multi user environments ;-)

(04 May '11, 07:26) Jasper ♦♦

Answer 4

"They are getting errors reported from the software that file already in use, file not found, resource record not found." I have had clients use real-time online backups that caused exactly what you are describing as database issues. Things like "Carbonite", "Mozy" and "Symform". The issue seems to be that the backup has the file locked (even though they claim it will not) creating the file in use error. If you are still having the issue I would look there.