[ale] stalled ftp/sftp transfers

Jim Kinney jim.kinney at gmail.com
Wed May 13 09:32:10 EDT 2009


It would be interesting to use QoS during the upload to adjust the bit
rate up and down randomly an see if the process will complete. I
suspect there is an upload cap based on time and bandwidth saturation
so that maybe not maxing out the upload bandwidth will allow the
process to complete.

Cable modem does NOT like uploads other than requests for downloads
and then it doesn't like large, sustained downloads.

I'm waiting for the anticompetetive lawsuits to start as people on
cable (and probably soon AT&T Universe) find issues downloading movies
from Netflix.

On Wed, May 13, 2009 at 8:24 AM, Ken Cochran <kwc at theworld.com> wrote:
> (Sorry for the top-post, hopefully quicker to read/summarize.)
>
> At the risk of this being OT, Googling this problem gets
> results mostly in Linux forums & discussions.  I'd say this
> is more an issue of "general networking & network services."
>
> "Local" network is Charter (cable).  Upload speed cruises along
> at some 50kb/s-ish for about an hour (hmm) & to about 135mb
> then it stalls.  Port status (netstat) looks good, whether I try
> PASV or not (ftp is on 20-21 or 20-something-hgh-around 58nnn).
> Tcpdump on the data port indicates *nothing* traversing once the
> stall happens (well, a packet every minute or two but doesn't
> look like any real data).  Netstat shows a send-q from the
> beginning & that is maintained during upload so I don't think
> that's a factor other than indicating that the output buffer
> is filled & working.
>
> Stalling happens on the firewall/NAT machine (directly
> connected to the WAN) with ncftp or the OS' (in this case
> FreeBSD) command-line ftp client and an OSX machine inside
> the NAT/firewall running its command-line ftp client.
>
> Dslreports doesn't have anything, umm... substantive...  umm...  yet...
>
> I'll likely have to resort to drive-net, e.g. more modern
> version of the station wagon full of backup tapes... :(
>
> -kc
>
>> Date: Wed, 13 May 2009 07:19:31 -0400 (EDT)
>> From: Mike Harrison <meuon at geeklabs.com>
>> To: "Atlanta Linux Enthusiasts - Yes! We run Linux!" <ale at ale.org>
>> Subject: Re: [ale] stalled ftp/sftp transfers
>>
>> On Wed, 13 May 2009, Ken Cochran wrote:
>>
>> > What should I investigate wrt ftp & sftp transfers that stall?
>> > I often get sftp downloads that stall and am now rather
>> > reliably getting stalls at about 135mb on ftp uploads, both
>> > PASV & non-PASV and with ncftp and (I'd guess) "traditional"
>> > (builtin) ftp clients.  Server appears to be running Proftpd.
>>
>> My formerly wonderful, now limited Comcast connection started
>> behaving this way a few months ago. Something upstream breaks
>> any open connection after x minutes. It affects playing a web radio
>> station, or ftp.   So far, rsync over ssh and scp or ssh itself
>> seem to be more resilient, and just "hang" for a while
>> but then they pick back up. My neighbors are seeing the same.
>>
>> It seems to break/stall a connection at the port level.
>> ie: I can open up another session while one is hung up.
>> And then the first one unfreezes in about a minute.
>>
>> My only point is: It may not be your end, the server, or the gear.
>> It may be an ISP along the way trying to limit bandwidth leaching
>> net radios, bittorrents, uh.. everything.
>>
>> Dang I miss the days of 2 DS3's and a Gig-E Upstream connection...
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>



-- 
-- 
James P. Kinney III
Actively in pursuit of Life, Liberty and Happiness



More information about the Ale mailing list