ACK and RST packets sent after successfully terminating TCP connection

[Jeremy Chadwick]

On Mon, Feb 15, 2010 at 10:07:32PM +0100, n j wrote:
> Hello Jeremy,
> 
> > Is it possible for you to upload these captures somewhere on the web?
> > tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient.
> 
> You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and
> the data have been anonymized, everything else has been left intact.
> There was no ICMP traffic between the hosts. Thanks for looking into
> it!

succ.pcap --

<skipping obvious stuff>
Packet #9:  client --> server: client requests TCP connection close (FIN+ACK)
Packet #10: server --> client: server sends ACK
<approximately 0.6 seconds passes>
Packet #11: server --> client: server announces TCP window size of 0,
            indicating TCP receive buffers are exhausted and that the
            client should wait before doing anything more
Packet #12: server --> client: identical re-sent ACK of packet #10

fail.pcap --

<skipping obvious stuff>
Packet #3: client --> server: initial handshake; TCP ACK
Packet #4: server --> client: server sends TCP RST.  Software on
           server likely closed the socket/fd
<approximately 0.75 seconds passes>
Packet #5: server --> client: server announces TCP window size of 0,
           indicating TCP receive buffers are exhausted and that the
           client should wait before doing anything more
Packet #6: server --> client: identical re-sent RST of packet #4
Packet #7: client --> server: confirms reset (RST+ACK)

Whatever this client/server protocol is, it isn't normal/standard.  It's
not something like, for example, HTTP, SSH, or FTP; It's a custom
protocol and one I haven't seen before.

Do you see the above awkward behaviour (zero-sized TCP window packets
followed by a retransmission of a prior packet) when using standardised
protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP?

If not, then the client/server software is probably to blame.  It may be
operating on a raw socket level, populating IP and/or TCP portions of
the packet itself rather than relying on socket(2) entirely.

If it uses standard kernel socket(2) functionality with PF_INET and
SOCK_STREAM, then I'd ask if the source is available publicly to be
analysed to determine if this behaviour is intentional or not.

Is there VPN and/or NAT involved between the client and server
(re: NAT: particularly around the server)?

Finally, is it possible to get "ifconfig -a" and "netstat -m" output
from the server?

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |