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

tcp previous segment not captured

0

we have put in a new server and netgear 48 port switch where previously they had a hub, Internet access is working perfect and they get 60Mb to the desks, however an issue that has started that was ok before is that 1 application on 4 machines out of 7 is getting eggtiming and they are being kicked out of the app (inhouse application that runs mainly with FTP) this happens randomly but frequently and other apps do not seem affected.

At points the trace log to one of the machine is showing tcp previous segment not captured.

Could anyone help me interpret the packet capture, apologies as i have not used it before.

asked 29 Mar '16, 09:30

Roadrunner123's gravatar image

Roadrunner123
6112
accept rate: 0%

Could you provide us a trace at a public accessible place like: cloud shark or dropbox

(29 Mar '16, 10:00) Christian_R
(30 Mar '16, 01:22) Roadrunner123

Are we talking about FTP or are we talking about some filetransfers done by another protocol like SMB? Because I can´t see any FTP traffic in your trace.

(30 Mar '16, 14:55) Christian_R

Thanks for commenting Christian, yes the propriatary software mainly uses FTP, i will run another trace this morning and upload it.

(31 Mar '16, 01:09) Roadrunner123

One Answer:

0

My interpretation is that

  1. the server application listening at port 8085 rejects several repeated attempts of 10.1.25.60 to connect; as the repeated attempts come from different ports and none of them succeeds, it does not seem to be caused by previous session using the same client side socket and closed shortly before. Some access rules at the server application are more likely. But I don't think it is a symptom of what you're after.

  2. the "previous segment not captured" can be seen only once, in frame 1723, but it seems to be a symptom of some kind of larger network failure than of just a loss of a single frame and thus a better indicator of an issue. The last "fine" frame is 1719, then there are some 78 seconds of silence, and then the client (10.1.25.60) uses ARP to find out the MAC address of the server so that it could send the next frame. The last "fine" frame has a relative seq number of 3016, the "previous segment not captured" one has a relative seq number of 3056, so there should have been a 40-byte-payload packet in the same direction but it has not been captured.
    Soon after, the server sends again an ACK to 3016 so it has also not received that 40-byte-payload packet, i.e. it is not only an issue of capturing. This seems obvious here as the capture was running at the server itself, but I mention that as it would be an important indicator if the capture would be taken somewhere else along the network path between the client and the server.
    Does the client machine happen to have several network cards (including wireless), i.e. if the proper interface would be down, could it be that the missing packet would be sent via a different interface (and lost because it would not reach the destination as there is no network route between that other interface and the server)?
    As you wrote that you've replaced a hub by a switch, I would have a look at speed/duplex negotiation settings on the ports of the switch (and compare them between ports to which different client machines are connected), as it seems to me as if the client's network interface would be occasionally down at L1. And, still following the same idea, can you compare the network adaptor type and manufacturer of those 7 machines, maybe the 4 affected ones have a common make/model different from the remaining 3? Experience shows that "some" Ethernet adaptors have speed/duplex negotiation issues with "some" switches even if settings of both are compatible to each other.

answered 30 Mar '16, 03:14

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

wow, thanks Sindy, the client machines are just average desktops with one network connection. i will have a look at the speed and duplex settings next and then the network adaptors.

(30 Mar '16, 03:25) Roadrunner123

One more point in completely different direction has come to my mind, can you capture simultaneously on the server and one of the problematic clients until you can see the issue happen? I'd like to be sure whether the client sends the missing frame (and so it got lost under way) or whether it does not send it at all. There could be issues like arp spoofing, causing the client to send it to a different MAC address, although it doesn't sound much likely as some client machines exhibit no problems when accessing the same server. But the issue is weird enough to look in all directions, and it is always useful to have a capture of the same occurrence of an issue from as many points along the path between the client and the server as possible.

(01 Apr '16, 06:32) sindy