Date: Mon, 15 Feb 2010 13:42:01 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-stable@freebsd.org Subject: Re: ACK and RST packets sent after successfully terminating TCP connection Message-ID: <20100215214201.GA71304@icarus.home.lan> In-Reply-To: <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com> References: <92bcbda51002150130i3a1baa4eha06b8ce4f90de486@mail.gmail.com> <20100215101148.GA56308@icarus.home.lan> <92bcbda51002151307x21f2ac2ax39f890566407bd74@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100215214201.GA71304>