While doing a file transfer using secure file transfer protocol, I am seeing the behaviour as given in the below image.
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 |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you share us a trace: https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Hi Christian, Please find the trace at the below link https://drive.google.com/open?id=0ByHA0TOU8EmCdWlyRHJ5YlExSjQ
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.
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.
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.