Why do FTP downloads stall under RH6.2 linux
Joe Mazz
my ISP for PPP dial-up
with a 56K PCI modem made by Actiontec.
Problem: Access to Web pages via Netscape 4.72 and interactive login
sessions via telnet work fine, with
transfer speed typically near the maximum throughput reported as by the
RH Network Monitor in GNOME.
The problem is when I try to download files via FTP, especially large
binaries (*.rpm or *.gz).
After a few hundred kilobytes, the FTP simply stalls. If it picks up
again at all, it is typically at very slow bps,
and then it crawls along between successive stalls. This happens whether
I use Netscape (Save link as...),
an ftp session started on the command-line, or even using the excellent
program 'wget' (e.g., 'wget ftp://whatever...').
Clue #1: While a file transfer is stalled, network access via Netscape
to view Web pages and read news
or email transfer at high speed, up to 56K.
Clue #2: I have ran tests that show the problem is not on the ftp server
side (e.g., busy anonymous FTP servers).
For example, ftp stalls also occur while trying to download files while
logged into my personal (Solaris) computer
at work just 10 miles away (with a T1 connected to the net), which has
no other FTP users or other heavy system load.
Clue #3: There seems to be no problem with my DNS setup, since I can
ping and connect to servers all
over the net by domain name or IP address number.
Clue #4: FTP downloads using the same modem and ISP never stall like
this running Win98!
Similar problems with FTP stalling under Linux have been reported
repeatedly in the news group archives
(via DejaNews.com), with no definitive answers posted as far as I can
tell.
The symptoms described above suggest that the problem may be in the
Linux kernel, fttpd, the PCI modem driver,
or something else at a 'low level' in the system. Can someone from
Redhat or any Linux network guru please
inform us how to trouble-shoot and solve this mysterious problem?
Thanks in advance for any leads...
-Joe
Anna
probs at all; I habitually use gftp and long downloads do not stall. From
time to time I use kfm to download via ftp and it, too, behaves well.
Perhaps there is something changed in your configuaration files? MTU
units?
I do have a roughly similar problem with task threading, however; if I
establish a connection, say with pan, and download a bunch of binaries, www
access through a browser is very, very slow; I sometimes have to hit the
reload button several times before it speeds up again. This happens across
and within applications, so it may be related to your complaint and it may
be an issue with RH.
In article <39971455...@earthlink.net>, Joe Mazz
<joe...@earthlink.net> pounded on his/her keyboard until this came out:
--
___________________________________________________
We are six billion humans: Three billion men trying to be just like each
other And one woman in three billion fantasies.
--Anna Merikin, 1999
____________________________________________________
Allen Ashley
Are you trying to ftp over a LAN with IP masquerade? If so, you have to
use the passive mode:
ftp -p
addinall
Joe Mazz <joe...@earthlink.net> wrote:
> Platform: RedHat 6.2 patched to kernel 2.2.14-6.0.1, using Earthlink
as
> my ISP for PPP dial-up
> with a 56K PCI modem made by Actiontec.
>
> Problem: Access to Web pages via Netscape 4.72 and interactive login
> sessions via telnet work fine, with
> transfer speed typically near the maximum throughput reported as by
the
> RH Network Monitor in GNOME.
> The problem is when I try to download files via FTP, especially large
> binaries (*.rpm or *.gz).
> After a few hundred kilobytes, the FTP simply stalls. If it picks up
> again at all, it is typically at very slow bps,
> and then it crawls along between successive stalls. This happens
whether
> I use Netscape (Save link as...),
> an ftp session started on the command-line, or even using the
excellent
> program 'wget' (e.g., 'wget ftp://whatever...').
I hope someone posts an answer because I have exactly the same
problem. My web browser (netscape) stalls more than 50%
of the time downloading mail, news or other web pages. A repitition
of 'reload, reload, reload, reload generally gets it, but it
is frustrating. Again, the Windows or Mac boxes connected
do not show this problem %-?
Luck,
Mark.
Sent via Deja.com http://www.deja.com/
Before you buy.
Jason A Martin
noticed some peculiarities:
1) This only occurs with ftp exchanges, (at least through my experience)
and typically on larger file gets.
2) it happens with masqueraded transfers or on transfers originating from
the server itself.
3) /sbin/ifup ppp0 has been putting a lock on the wrong serial port
4) The behavior changes when I use setserial to reassign the uart type:
8250: Every transfer work perfectly, as you would expect for
this uart. it is slow, but reliable. Very slow, but
all transfers work.
16550a: should work, my modem is new and not a winmodem. In fact
it does work on everything but some ftp transfers. not
all, but some. speed is good, except the little problem
most other uarts function like the 16550a as far as I can tell.
5) Obviously is not a modem issue because windows 9x and NT 5 have no
issues with it.
6) /dev/ttyS0 and /dev/ttyS2 share irqs, but I think this is standard.
7) I believe that this problem may have originated when I installed the
2.2.16 kernel, though I have not yet tested this hypothesis.
8) the client software is not the issue either, as ftp, ncftp, and
netscape (linux) and opera/explorer/ftp (win/masqueraded machine)
all give the same trouble.
I hope that these leads can give someone some insigt into a
solution. My system is offline at the moment and unfortunately no solutions
can be tested. as a temp solution for these downloads I have been
switching the uart to 8250 (requires restarting of ppp0) and this is a
pain. not to mention the 20 meg downloads at 2k/s take quite a while.
If I can't get it fixed then my hope is taht the 2.4.x kernels do
not cause the same problem. I am curious if anyone has this problem who
is NOT connecting over a modem. That is why I think the problem
originates through the serial port. Good luck,
Jason
Robert Kiesling
It could be due to several reasons, but there seems to be due to an
incompatibility with the ftp server daemon, as it occurs both with NT
and Linux servers. I've noticed it mostly when connecting to wu-ftpd.
I'm not sure exactly what daemon NT servers use. It might be due to
large data packets overrunning the buffers, but there's no conclusive
proof of that. About the only real fix I've been able to come up with
is to use the Linux port of the FreeBSD ftp server, which you'll need
to build on your own system. It's on freshmeat, at least, and should
be on the standard source archives.
Robert
(@ home)
Larry Condon
Wget has never failed to retrieve a full file for me, even through a
disconnect/reconnect sequence. As to the ftp programs, most problems seem (to
me) to be active/passive transfer issues
Rinaldi
no email please, not my box.
Jason A Martin
let me ask this: why should changing the uart type to 8250
allow transfers to complete that the 16550a will not?
this is the most puzzling part.
The 16550a has a 16-byte buffer where the 8250 has only one byte.
also 16650 and 16750 uarts work fine with my modem except in the case
of certain ftp gets. do you think that active/passive mode should have
anything to do with this? (by the way, if I am wrong on the uart specs
let me know)
Jason
Larry Condon (dar...@bellsouth.net) wrote:
: man wget
Rooie
problem is ftp timeout's on a machine thats 'behind' linux (getting the
internet packets from the linux box) Then your problem is a MASQUARADE
problem. Change your MASQ timeout settings to avoid this. check the man
pages from IPCHAINS.
( ipchains -S seconds seconds seconds )
Good luck
"Jason A Martin" <mar...@mail.auburn.edu> wrote in message
news:8ngtqg$7t8$1...@ultranews.duc.auburn.edu...
Michael Iwaki
installation, for Redhat 6.2, there is a note stating that it will not install
the network daemon, inetd. Network-related services such as finger,telnet,talk
and ftp will not work. If you require these services, choose a server-or
custom-class installation.
ray
I had an issue sorta similar. FTP would disconnect after some of the file
transferred.
Worked OK in all other respects. This was on RH6.1, I think, using a USR
56K internal.
It turned out to be the MTU value. This has to be reduced by some discreet step,
which
I don't recall now, but you can find that on the web. Shortly after that got
solved, cable
internet became available, so I am sketchy as to exact values, and where I set
that. But,
that fixed it, and much improved the transfer throughput, as a bonus.
CROSSPOSTING is a Bad Idea :)
--
Ray R. Jones
Errors have been made. Others will be blamed.
ad...@gordo.penguinpowered.com
HTTP://gordo.penguinpowered.com
Nick
> What installation option did you use? If you used Workstation-class
> installation, for Redhat 6.2, there is a note stating that it will not install
> the network daemon, inetd.
Where is the note?
> Network-related services such as finger,telnet,talk
> and ftp will not work. If you require these services, choose a server-or
> custom-class installation.
If I choose custom, what do I need to install to get e.g. inetd
Nick
-----We Solve your Computer Problems---
Founder of the Prolifics User Group
Hal Burgiss
>In a previous article Michael Iwaki wrote:
>> What installation option did you use? If you used Workstation-class
>> installation, for Redhat 6.2, there is a note stating that it will
>> not install the network daemon, inetd.
>
>Where is the note?
>
>> Network-related services such as finger,telnet,talk and ftp will not
>> work. If you require these services, choose a server-or
>> custom-class installation.
>
>If I choose custom, what do I need to install to get e.g. inetd
$rpm -Uvv /mnt/cdrom/Redhat/RPMS/inetd*
This is my PATH. Make sure the CD is mounted and PATH is correct.
--
Hal B
h...@foobox.net
hbur...@bellsouth.net
--
The Drag
documentation. All of this is covered in a couple of paragraphs.
You could always complete the workstation install and then install the
rpm for netkit-base.
On Sun, 10 Sep 2000 20:10:06 +0100, Nick <ni...@upsonuk.com> wrote: