Date: Sat, 29 Dec 2001 22:54:47 +0000 From: Dominic Marks <dominic_marks@btinternet.com> To: "Crist J . Clark" <cjc@FreeBSD.ORG>, Eugene Grosbein <eugen@www.svzserv.kemerovo.su> Cc: questions@FreeBSD.ORG Subject: Re: strange behavour of stock ftpd in STABLE: ports exhausion? Message-ID: <E16KSMr-0004vW-00@carbon.btinternet.com> In-Reply-To: <20011229131039.J93411@blossom.cjclark.org> References: <20011229170326.A98378@svzserv.kemerovo.su> <20011229131039.J93411@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 29 December 2001 9:10 pm, Crist J . Clark wrote: > On Sat, Dec 29, 2001 at 05:03:26PM +0700, Eugene Grosbein wrote: > > This is not really a topic for -stable. Diverted to -questions. > > > I use standard ftpd coming with FreeBSD 4.4-STABLE. > > > > My /etc/sysctl.conf contain these lines: > > > > net.inet.ip.portrange.hifirst=49152 > > net.inet.ip.portrange.hilast=49200 > > > > This should restrict number of concurrent passive mode > > connections to 49. > > Why would it? Because ftpd uses these sysctls when choosing ports to use for passive connections. This is related to the -U option (see man ftpd). > > But this does much more. Suppose, a ftp client has good link to > > server, 100Mb ethernet in my case. Suppose it uses passive mode > > and starts to download very bug number of files sequentially, one > > then next then next... It says TYPE I, PASV, RETR, TYPE I, PASV, > > RETR... > > So, it can download 49 files in a row then server says > > 425 Can't open passive connection: can't assign requested address > > I don't see why it would say that, but anyway... For each passive mode transaction one of the ports in the range is consumed. When it runs out of ports to use, you get this error. > > If client does not break control connection, waits a little and > > starts to download the rest of files, it can download next 49 > > files and so on. > > > > There are no other clients connected meantime. > > How can this happed? > > Well... why wouldn't it? You get the 'can't assign requested > address' error when you try to open a connection on top of an > existing one. If the new TCP connection isn't trying to use an > existing <source address, source port, destination address, > destination port> quartet (notice that the client changes the > source port too), it should work fine. The problem is that ftpd doesn't appear to recycle the ports it uses. Ideally one client using passive mode should only ever consume a single port from the acceptable range. Eugene's problem is that ftpd is not doing this, and the server becomes unresponsive to passive mode connections after this point. (I have successfully replicated the behaviour he noticed here. Someone suggested earlier that use of the SO_REUSEADDR socket option could potentially fix this issue. However I see a number of problems with this. 1. Once a transaction is completed (such as a LIST) surely the socket used for this transaction should be immediately freed. So this would appear to be a bug (?). 2. Also, from my reading of the setsockopt manual page what SO_REUSEADDR actually does is to allow the sharing of the socket between multiple processes. If we share a socket before its current operation is complete we may cause the network streams for one, or both of the clients to be corrupted (At least, thats what I think the man page was communicating). If this is indeed a bug then I suspect the fix is related to the closing of used sockets for passive mode connections. I'm going to try investigate a little further. I'd like to point out that my knowledge of the FTP protocol or how some of the syscalls (eg: setsockopt) work in practice is not full enough for this to be considered reliably correct. finally: > With such a low number of ports available in your high port range, > yes, but there are 16383 by default, which ought to be more than > enough. The range can be made even larger if you choose. While I agree, if this is indeed a bug, it still needs fixing. Thanks -- Dominic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E16KSMr-0004vW-00>