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

Capture machine dropping packets originating from it.

0

Hello,

I have come across this weird behaviour. Session is a standard HTTPS session to a webserver on our internal network.

The session starts fine : SYN, SYN/ACK, ACK Then TLS : Client Hello, Server Hello.

The client Hello is Seq 1, Ack 1, Len 517 Server Hello is Seq 1, Ack 518, Len 137.

The next packet in the capture file is from the client (which is also the machine Wireshark is running on) : Seq 569, Ack 138, Len 536. At this point WS complains about "TCP Previous Segment not captured", which makes sense given the Seq number... except that Wireshark is running on the client machine, so the network has not been involved at all in dropping this packet. So where did it go ??

The next two packets are a DUP ACK from the server, and then a retransmit by the client, which shows that it's not just that WS didn't capture the packet, it really did not go out over the network.

From there the session continues normally.

The client machine is Windows 7 Enterprise SP1 64bit, fairly up to date, and running nothing very out of the ordinary. Client app is Chrome 47. No system firewall enabled, only Symantec Antivirus (for its AV scanning ability, not firewall). WS version 2.0.0, WinPCAP 4.1.3.

Does anyone have a brilliant idea what could cause a client machine to eat a packet in the network stack like that ?

Thanks,

asked 12 Jan '16, 23:48

Jeremy%20Gibbons's gravatar image

Jeremy Gibbons
6112
accept rate: 0%


One Answer:

0

Please search through the site for similar questions. Many kinds of security software are capable to mysteriously steal packets, even if they are not primarily firewalls, so you may have to disable your Symantec Antivirus completely to verify. The other subject to search for here (but less likely to apply to your case as part of the traffic is visible to you and as the packet seems to really have been lost completely, not just in the capture) is "tcp chimney" and "tcp offloading".

answered 13 Jan '16, 00:50

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 13 Jan '16, 00:52

@sindy I did, but did not see anything matching these symptoms. TCP Offload / Chimney would seem to be more drastic (I would not be seeing any TCP traffic at all, whereas here I am missing a single packet that got gobbled up somewhere in the network stack). I am aware of most of the usual traps for common WS use so I'm really puzzled as to what is happening. I will try and have SEP be deactivated, and see if I can reproduce then. Thanks.

(13 Jan '16, 01:13) Jeremy Gibbons