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

Client sends RST after FIN,ACK

0

While doing a file transfer using secure file transfer protocol, I am seeing the behaviour as given in the below image.

wireshark output

Instead accepting packets from server, it simply sends a RST. Found a similar case. https://stackoverflow.com/questions/12320998/client-sends-rst-to-server-after-fin-ack-during-ssl-handshake

But wasn't helpful Please help.

Regards, Joemon

asked 08 Jun '17, 09:30

user_shark's gravatar image

user_shark
6224
accept rate: 0%

(08 Jun '17, 11:48) Christian_R

Hi Christian, Please find the trace at the below link https://drive.google.com/open?id=0ByHA0TOU8EmCdWlyRHJ5YlExSjQ

(08 Jun '17, 22:14) user_shark

What exactly is your problem? That RST itsself is not really bad at that moement. Some systems send an RST to avoid TIME_WAIT2. But it also can be sent due to the Encrypted alert.

If you have problems with unfinished file transfers, encrypted alert seems to be your problem. Some other side findings can be seen in your trace... Duplicate IP and Spanning Tree Topology Changes.

(09 Jun '17, 14:15) Christian_R

Yes Christian, the problem is with unfinished file transfer. Also can you explain on how is this encrypted alert different from the previous alerts. As you can see for the same connection, the client has accepted many such encrypted alerts sent previously by the server.

(11 Jun '17, 21:27) user_shark

Hi Christian,

Please ignore the previous captures. Kind of getting a different traces now and the same issue. Please find below the capture from client and server side. https://drive.google.com/open?id=0ByHA0TOU8EmCZmgweDl3Wi1HZG8 https://drive.google.com/open?id=0ByHA0TOU8EmCWVpPMDM3V0o0MUU

Its showing unreassembled packet [incorrect tcp checksum] Even though I was able to get rid of this error by disabling tcp checksum offloading, still the issue remains.

(12 Jun '17, 06:49) user_shark