net.inet.ip.portrange.randomized=1 hurts

Dmitry Pryanishnikov dmitry at atlantis.dp.ua
Wed Jun 2 02:54:00 PDT 2004


Hello!

> Date:      Tue, 1 Jun 2004 19:07:35 -0500 (CDT)
> From:      Mike Silbersack <silby at silby.com>
>
> On Tue, 1 Jun 2004, Andre Oppermann wrote:
>
>> A port should not be reused this fast.  Maybe the randomness isn't
>> so random after all and choses the same port over again and again?
>
>We use arc4random, so I don't think that's likely, but it is possible.

 OK, I would like to provide some statistics based on FTP server log.
In the following table, first column is the total number of PORT commands
per FTP session, second is the number of PORT commands between the first and
second occurence of reused port (which is the cause of "425" error), third
column is the interval between those occurences in secons:

Total # of PORT comm.	Interval, # of PORT	Interval, sec

	558			35			50
	336			50			20
	165			160			55

So, it doesn't seem to me that random number generator works badly, but any
randomness doesn't _guarantee_ that port number won't repeat within 2*MSL
seconds, does it? Also I have heard of algorithms (but can't recollect now)
that actually guarantee non-repeatness of the large portion (up
to the interval range) of pseudo-random sequence. If we had such an algorihm
for random port allocation, we won't get reused ports so often (by default,
portrange.hilast=65535 and portrange.hifirst=49152, so theoretically we would
have 16383 non-repeated port numbers before the first repeat).

> > A simpler solution might be to use passive mode.  I think that you can set
> > that somewhere in the install options.

 I'm looking at "Options" menu right now, but I don't see such an option -
just "FTP username", no more.

> Something fishy must be going on here, because sysinstall doesn't make too
> many ftp connections, does it?  Port recycling issues should only be
> showing up in applications which make thousands of connections per minute.

 It all depends on definition of "too" ;) Actually, sysinstall has to transfer
154 chunks of data just to install 4.10's base; if you want sources, add
another 316 chunks.

 But actually my concern is not about sysinstall, but about real-life everyday
usage of 4.10+ based clients and servers. Will revision 1.147 of
sys/netinet/in_pcb.c solve this problem on server's side (by letting server
to open this server.20->client.PORT TCP session despite having another
server.20->client.PORT session in TIME_WAIT)? If so, it seems like a real
solution for this problem, and I'll wait for it's MFC.

P.S. I don't think that net.inet.ip.portrange.randomized=1 hurts local
MySQL connections, since MySQL AFAIK doesn't use TCP during localhost
connection at all; it uses socket instead.

Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE


More information about the freebsd-net mailing list