First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

What is the best way to find out what is causing TCP acked unseen segment.

  • retag add tags

I am try to find the cause of slow receipt printing, I have several captures from the server side looking at the clients having the issue. On all the captures I see TCP acked unseen segment, this application talks to several servers I was told the one I am looking at would be the best one to capture the conversation for the receipt print application.

asked 2018-11-15 13:38:41 +0000
This post is a wiki. Anyone with karma >750 is welcome to improve it.
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

1

TCP Acked Unseen segment is Wiresharks way of informing you that in the capture you see ACKs for packets that were not seen by Wireshark i.e. they are not in the capture, but the data has been received by the sender of the ACKs.

The typical cause for this is a poor capture. I'd guess that the server where you're capturing is not capable of capturing all packets to/from the server.

Provided you can do the capture yourself, you can try to use capture filters, packet truncation or other ways of lowering the amount of data you must capture.

Then I'm sure these false positives will disappear.

NJL's avatar
120
NJL
answered 2018-11-15 16:09:00 +0000
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

I have brand new experience what this may mean alike - a server responds over different interface than one would expect/desire.

Imagine you have 2 subnets. X and Y. Client is on the Y, our VMWARE ESXI server on both due to vmkernel NICs on each. Client tries to reach server on its X address (instead of directly at Y), however server responds, due to flat routing stack, over its Y interface because client (flow source IP@) is right there ==> routing asymmetry. Simply only explanation to me how it detects and displays that message is that TCP SYN-ACK response comes from different MAC@ than initial SYN has as destination (Y subnet gateway).

We came to this by accident of one guy doing GUI HTTPS access, my central wireshark and even vmk0 (X subnet) dumps showing just cycles of client's SYN and RST packets, then finally client's wireshark showed this "unseen" segment and tracing back MAC@ withing infra got us to vmk1 server interface. Rather logical behavior, routers do exhibit the same. Easiest solution for guy was to access ESXI directly for Y subnet and fix our DNS infra with both IPs for ESXI server so DNS response would fit anybody accessing the server by name.

PeterG's avatar
1
PeterG
answered 2023-01-04 09:50:18 +0000
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer