On Mon, Feb 04, 2002 at 10:44:56AM +0100, Pascal Gienger wrote:

A typical FTP session goes like this:

ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. 226 Transfer complete. ftp> pwd 257 "/" is current directory. ftp> cd pub 250 CWD command successful. ftp> get 8_Recommended.zip 200 PORT command successful. 150 Opening BINARY mode data connection for 8_Recommended.zip (54820860 bytes). 426 Data connection: Connection reset by peer. local: 8_Recommended.zip remote: 8_Recommended.zip 1696312 bytes received in 2.8 seconds (600.33 Kbytes/s) ftp> quit 221 Goodbye.

Funny enough, I tried it on Solaris 8 x86 and it works. Is there an ugly bug lying around in Solaris? :(

It seems to be one, yes. FIONREAD works for a while, than it returns invalid values.

Funny: If you compile Debug-Support in (-DCOMPILE_DEBUG) and you set the level to highest verbosity, no error appears...

set "umask 0" before you start the proxy: u=$(umask) ; umask 0 ; ftp-proxy ; umask $u

is there a Problem with speed regarding Solaris libraries?

Hmm.. if I run (same machine) the proxy on OpenBSD, FreeBSD or Linux, it runs fine/fast, but on Solaris 8 x86 it is much slower. IMHO the network driver that Solaris runs with 10MBit only? I'll test it the next weekend again...

With verbosity level 3 (debug 3), I get this in ftp-debug.log:

10:40:34 < 687> Srv-Data -> Cli-Data 10:40:34 < 687> ll_write Cli-Data 6=134.34.1.61: 1460/10741740 bytes 10:40:34 < 687> ll_read Srv-Data 5=134.34.3.2: 1460/10743200 bytes 10:40:34 < 687> Srv-Data -> Cli-Data 10:40:34 < 687> ll_write Cli-Data 6=134.34.1.61: 1460/10743200 bytes 10:40:34 < 687> closed: Srv-Data 5=134.34.3.2 10:40:34 < 687> about to destroy Srv-Data 10:40:34 < 687> config_bool: s='(nil)' n='FailResetsPasv' d=0 10:40:34 < 687> config_bool: result=0 10:40:34 < 687> deleting HLS Srv-Data -1=134.34.3.2:9186 10:40:34 < 687> about to destroy Cli-Data 10:40:34 < 687> USER-INF Transfer for 134.34.1.61 completed: RETR '8_Recommend ed.zip' read 10743200/10 byte/sec 10:40:34 < 687> deleting HLS Cli-Data -1=134.34.1.61:51905 10:40:34 < 687> ll_read Srv-Ctrl 3=134.34.3.2: 48/2382 bytes 10:40:34 < 687> gets Srv-Ctrl 3=134.34.3.2: 46 bytes '426 Data connection: Con nection reset by peer.' 10:40:34 < 687> TECH-DBG from Server-PI (3): '426 Data connection: Connection reset by peer.' 10:40:34 < 687> from Server-PI (3): '426 Data connection: Connection reset by peer.' 10:40:34 < 687> printf Cli-Ctrl 0=134.34.1.61: 48 bytes '426 Data connection: Connection reset by peer.' 10:40:34 < 687> ll_write Cli-Ctrl 0=134.34.1.61: 48/2198 bytes 10:40:40 < 687> ll_read Cli-Ctrl 0=134.34.1.61: 6/397 bytes

You see the "closed: Srv-Data 5=134.34.3.2" even when the file is not fully transferred. What is going wrong here? :(

socket_ll_read gets called only, if select says there _is_ data avaliable to read. if I_NREAD returns >=0 and len=0 a close will be called (no error and no data ==> EOF). /* ** Get the number of bytes waiting to be read */ len = 0; #if defined(I_NREAD) && (defined(sun) || !defined(FIONREAD)) if (ioctl(hls->sock, I_NREAD, &len) < 0) { hls->xerr = errno; syslog_error("can't get num of bytes: %s %d=%s", hls->ctyp, hls->sock, hls->peer); return; } #if defined(COMPILE_DEBUG) debug(4, "ll_read: I_NREAD reported %d bytes for %s", len, hls->ctyp); #endif #else if (ioctl(hls->sock, FIONREAD, &len) < 0) { hls->xerr = errno; syslog_error("can't get num of bytes: %s %d=%s", hls->ctyp, hls->sock, hls->peer); return; } #if defined(COMPILE_DEBUG) debug(4, "ll_read: FIONREAD reported %d bytes for %s", len, hls->ctyp); #endif #endif /* ** Check if the socket has been closed */ if (len == 0) { #if defined(COMPILE_DEBUG) debug(1, "closed: %s %d=%s", hls->ctyp, hls->sock, hls->peer); #endif close(hls->sock); hls->sock = -1; return; }

When a LIST ("dir") gives no output, the same thing happens but no "426 Data connection: Connection reset by peer." appears.

Any hints left?

No... not at the moment. The proxy should pass the response from server to client... Gruesse, Marius Tomaschewski -- SuSE Linux AG, Nürnberg - SuSE Labs, Product Developement PGP public key available: http://www.suse.de/~mt/mt.pgp Fprint: EA 1F 92 75 1A F9 82 07 A1 28 DE 7A 32 E8 97 18