The replacement of libc didn't do anything... Here is an example of what I'm seeing during the sample FTP of the vmlinuz and vmlinuz.gz files... 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 [EMAIL PROTECTED] (Seattle) > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-net" in > > the body of a message to [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]
