Wireshark – How to Find Cause of Incomplete Download

If you are capturing to memory only and stopping when the buffer runs out, then in the case of a broadcast storm the last frame time will be when the buffer ran out of memory. I'm not sure why you'd want to do this instead of capturing to disk.

There is no such thing as a bad TCP packet, unless you are expecting to find a packet corrupted on its way to your capture point, in which case the NIC might drop it before sending it up to the OS.

The string you've shared it just means one party tried to connect to the remote party and never received a response, so this is what you want to look for in Wireshark:

(Assume 1.2.3.4 is the client and 4.3.2.1 is the server)

• A SYN packet (tcp.flags.syn == 1) from client to server (ip.src == 1.2.3.4 & ip.dst == 4.3.2.1) that it has been retransmitted (tcp.analysis.retransmission)
• When you have located it, right-click on that packet and select "Follow TCP stream". Close the pop up window you'll get with the raw contents of the connection.

You'll be left with a filter on a specific tcp stream and you might see this behaviour:

• A SYN packet is sent
• A second SYN packet is sent 3 seconds later
• A third SYN packet is sent 6 seconds later
• A fourth SYN packet is sent 12 seconds later

And you might never see a packet coming from 4.3.2.1 to 1.2.3.4;

Your real problem might be:

• A firewall in the path.
• Service is not listening at destination.
• There's no route to the destination, so the packet gets sent to a default route at some point and dropped silently (probably leaving your Internet edge?)