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

tcp stream help

0

Can anyone help me with this TCP steam/capture? End result is the client using faxfinder can't connect to the server.

thanks in advance

http://img547.imageshack.us/img547/6901/m3o.png

asked 09 Jul '13, 15:04

wireuser70's gravatar image

wireuser70
1112
accept rate: 0%

Thanks for the prompt replies. I have even more information to share. I ran wireshark captures on the port going to the client on the same switch but I don't see any of the [syn, ack] from the server. Its like the packets are getting lost in the switch.

(10 Jul '13, 13:09) wireuser70

NVM!!!! traffic was leaving a different port on the switch. :P

(10 Jul '13, 15:56) wireuser70

2 Answers:

3

That's an interesting trace. Looks like the client sends a SYN to the server, gets a SYN/ACK back, but instead of finalizing the three way handshake the client aborts with a reset. I have seen something like this before, when the timeout setting for the connection was so short that the client gave up before the SYN/ACK arrived - which meant that the port was already closed when it "finally" came in, resulting in a reset. In your case the timing is relatively fast, so this looks pretty strange.

I guess you captured at the server (from the name in the title bar) - what you need to do is capture at the client to see what it sees. Maybe the client is innocent and a device between client and server is misbehaving. Capture at the client and the server at the same time, and compare the session handshake between both captures. You should be able to see any difference - but if there isn't any (meaning, you see the exact same SYN - SYN/ACK - RST sequence at the client) your client software is faulty.

answered 09 Jul '13, 16:44

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 09 Jul '13, 16:45

1

If there any Firewall or Loadbalancer involved? If so, it may cause the RST packet due to security restrictions. Did you see any ICMP packets in the capture file, like "administratively prohibited"? If so, that would be another sign for a problem with an intermediate system and not client and/or server.

If neither of the above is true in your environment (which I believe, because of the time deltas between the packets):

As @Jasper suggested. Please capture at the client and at the server and compare the capture files to figure out who actually sends the RST packet. If possible post the capture file somewhere (google docs, dropbox, etc.), so we can have a look as well.

Regards
Kurt

answered 10 Jul '13, 01:19

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%