ftp result - Netout :Connection reset by peer

[azztigin]

Hi,

Through a vpn connection, here's what happens when I do an ftp to an HP-UX 11.00 server:

ftp> bin
200 Type set to I.
ftp> put openssh-3.9p1-B.11.00-RISC20.depot
200 PORT command successful.
150 Opening BINARY mode data connection for openssh-3.9p1-B.11.00-
RISC20.depot.
> Netout :Connection reset by peer
426 Data Connection: Connection reset by peer.
ftp: 65535 bytes sent in 189.28Seconds 0.35Kbytes/sec.
ftp>


seems like the connection fails every time I do an ftp.

Pls help.

[G. Vrijhoeven]

Hi Jose,

May be your VPN connection fails becouse of a timeout. Try the hash command before you issue the get.
Now a # is printed when a k is transmitted and there will remain some activity on the line between you and your provider.

Regards,

Gideon

[RAC_1]

As this is a ftp over a VPN connection, is there a firewall between??? If yes, can you check the filrewall log??

Also can put/get a small file?(small in size)

Anil

[Mark Greene_1]

Can you verify that you aren't filing a file system? That will always stop an ftp transfer.

mark

[azztigin]

Hi mark,

What do you mean by filing a file system?

[rick jones · Accepted solution]

Connection reset by peer means that this end of the TCP connection received a TCP RST (reset) segment from what it believed to be the remote. It could be that the remote wasn't getting data fast enough to suit its tastes and closed its end. It could be that there is an intervening firewall that had a timeout (that your transfer time was 189 seconds sounds rather like a 180 second timeout.

That there was only 65535 bytes of data in 189 seconds seems to suggest there was trouble transfering data across the VPN. There are likely TCP retransmissions and retransmission timeouts in the netstat -p tcp output, and those would probably track as you try to send the file again.

If it happens with the same file over and over, it suggests that some piece of equipment between the two ends is encountering a data-dependent failure - that is the data pattern in the file transfer is unmasking a bug in some bit of kit along the way. You can test that by transfering a different file - you could even try doing a gzip -9 on the .depot file, and transfer the .gz version to change the pattern.

Filling a file system is just what it sounds like. A file system has a fixed capacity (just like a disc), and if you reach that capacity it can take no more.

You could also try some netperf TCP_STREAM tests between the two endpoints http://www.netperf.org/

(However, I'm a bit suspicious of the 65535 byte count there - sounds more like what made it into the socket buffer rather than what might have made it across the network. That the remote reset the connection makes the transfer count a bit suspect as well - there was no exchange of FIN's so there is no real knowledge of what bytes made it. In that sense, the ftp client on your sending system (btw, what is the sending system) is a bit buggy by giving that output.

[Tyler Easterling_1]

The VPN software could be confused by ftp's ill-behaved protocol. Try running in passive mode.

ftp> passive

Might help
Tyler