ftp> cd /
250 CWD command successful.
ftp> get vmlinuz
200 PORT command successful.
150 Opening BINARY mode data connection for vmlinuz (406263 bytes).
#### <-- NOTE: at this point the xfer stalls... This is what the netstat looks
like:
mml1:/etc/rc.d# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 124 xx.xx.xx.xx:23 yy.yy.yy.yy:4676 ESTABLISHED
tcp 0 0 xx.xx.xx.xx:21 zz.zz.zz.zz:1710 ESTABLISHED
tcp 0 49640 xx.xx.xx.xx:20 zz.zz.zz.zz:1712 ESTABLISHED
and then I did a CTRL-C
receive aborted
waiting for remote to finish abort
426 Transfer aborted. Data connection closed.
226 Abort successful
4380 bytes received in 1.4e+02 seconds (0.03 Kbytes/s)
ftp> get vmlinuz.gz
200 PORT command successful.
150 Opening BINARY mode data connection for vmlinuz.gz (396813 bytes).
################################################################################
################################################################################
################################################################################
################################################################################
###################################################################
226 Transfer complete.
396813 bytes received in 78 seconds (5 Kbytes/s)
ftp> quit
221 Goodbye.
The netstat's below show the 'hung' transfer from the first GET, and shows the
progress of the second one that succeeds...
mml1:/# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 126 xx.xx.xx.xx:23 yy.yy.yy.yy:4676 ESTABLISHED
tcp 0 0 xx.xx.xx.xx:21 zz.zz.zz.zz:1710 ESTABLISHED
tcp 1 52965 xx.xx.xx.xx:20 zz.zz.zz.zz:1712 CLOSING
tcp 0 45260 xx.xx.xx.xx:20 zz.zz.zz.zz:1713 ESTABLISHED
mml1:/# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 126 xx.xx.xx.xx:23 yy.yy.yy.yy:4676 ESTABLISHED
tcp 0 0 xx.xx.xx.xx:21 zz.zz.zz.zz:1710 ESTABLISHED
tcp 1 52965 xx.xx.xx.xx:20 zz.zz.zz.zz:1712 CLOSING
tcp 0 33580 xx.xx.xx.xx:20 zz.zz.zz.zz:1713 ESTABLISHED
mml1:/# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 126 xx.xx.xx.xx:23 yy.yy.yy.yy:4676 ESTABLISHED
tcp 0 24 xx.xx.xx.xx:21 zz.zz.zz.zz:1710 ESTABLISHED
tcp 1 52965 xx.xx.xx.xx:20 zz.zz.zz.zz:1712 CLOSING
tcp 0 34734 xx.xx.xx.xx:20 zz.zz.zz.zz:1713 FIN_WAIT1
mml1:/# netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 126 xx.xx.xx.xx:23 yy.yy.yy.yy:4676 ESTABLISHED
tcp 0 0 xx.xx.xx.xx:21 zz.zz.zz.zz:1710 TIME_WAIT
tcp 1 52965 xx.xx.xx.xx:20 zz.zz.zz.zz:1712 CLOSING
tcp 1 0 xx.xx.xx.xx:20 zz.zz.zz.zz:1713 TIME_WAIT
I know that size doesn't matter, because I just completed a FTP GET from this
problem machine with a binary file size in excess of 22MB.
Thanks...
Barry
Barry Treahy wrote:
> Clayton Weaver wrote:
>
> > I wonder if it's downloading in ascii ftp mode instead of binary. That's
> > the first thing to check when someone mentions "garbled via ftp". I would
> > have thought http servers would simply always use binary mode, since that
> > works for both text and binary files, but maybe binary mode is broken in
> > your ftpd, and only in one direction?
>
> I've tested with two http servers, Apache and Roxen... Both fail on these
> files...
>
> As for the FTP, I know better and an example is the .33 kernel I built on the
> machine. Since its a remote machine, before I rebooted, I tried to D/L the
> kernel to another Linux PC with the same config and the FTP's failed... Only
> after I gzip'd the file could I D/L it and the kernel worked great on the test
> machine, so I rebooted the remote machine which too rebooted fine... The
> kernel upgrade did not resolve the problem though.
>
> A suggestion to swap out the libc is in process...
>
> >
> >
> > Sounds bizarre, but that doesn't rule it out.
> >
> > Note: linux ftpd on kernel 2.0.29 works here when called from OS/2's web
> > browser. I don't have (or Web Explorer ignores, I forget which at the
> > moment) pdf->acrobat in mime.types on the OS/2 box, so Web Explorer
> > always asks whether I want to download a pdf url that refers to a pdf file
> > on the linux server. If I respond "yes", the pdf file is downloaded via
> > ftp from the linux box to the OS/2 box, and acrobat on OS/2 doesn't report
> > any problem viewing the downloaded file when I suspend the web browser
> > to take a look at the pdf file. The linux box runs the wn web server and
> > Dave Holland's ftpd 1.8 (from netkit-0.10), which hasn't evidenced any
> > file corruption problems in either direction.
> >
> > Regards, Clayton Weaver cgweav@eskimo.com (Seattle)
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-net" in
> > the body of a message to majordomo@vger.rutgers.edu
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.rutgers.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu