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 j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
