RE: ip local port range

[Bastiaan Bakker]

> -----Oorspronkelijk bericht-----
> Van:	Mike A. Harris [SMTP:[e-mail]]
> Verzonden:	Monday, June 26, 2000 12:41 PM
> Aan:	Bastiaan Bakker
> CC:	[e-mail]
> Onderwerp:	Re: ip local port range
> 
> On Wed, 21 Jun 2000, Bastiaan Bakker wrote:
> 
> >As has been dicussed on this list in April, Linux does not follow the
> >IANA recommendation to use port number 49152 and higher for dynamic
> >ports. Albert D. Cahalan suggested changing the current range of 1024
> >till 4999 into  51024 till 514999. David Miller said 'Ok, this needs to
> >be fixed then.' but Andi Kleen objected that the change would cause
> >problems with poorly configured packes filters.
> 
> The packet filters need to be fixed then.  I've been reading the
> /proc file local-port-range inside my firewall scripts ever since
> I discovered it.  I assumed that this is what the file's purpose
> was for in the first place, as well as to change the range if the
> occasion is needed.
> 
> It does really make more sense IMHO to use higher port numbers
> though since they are less likely to hit ports that daemons
> require.
> 
> >Since then, it has been quiet about the topic, and the kernel has not
> >been changed.
> 
> Is it not as simple as changing a single #define or
> two?
> 
	Yes, it is that simple: you just have to change the
sysctl_local_port_range variable in net/ipv4/tcp_ipv4.c:

	/*
	 * This array holds the first and last local port number.
	 * For high-usage systems, use sysctl to change this to
	 * 32768-61000
	 */
	int sysctl_local_port_range[2] = { 1024, 4999 };

	Note that the suggested alternative range is also wrong :-)

> >I would like to argue in favour of changing the range: first,
> >it's the 'right' thing to do. Secondly, the old range generates
> >problems with applications that expect to be able to bind to
> >'their' port. In particular, I've experienced failures with
> >HylaFAX, because the faxmail delivery agent uses port 4558,
> >which at random times already was occupied. Thirdly, it's
> >trivial to get back the old range with sysctl if you need
> >compatibilty with broken packet filters. There is still time to
> >do this IANA compliancy change now, once 2.4.0 is out we have
> >to wait until at least 2.6, which may be a rather long time.
> 
> I think that this makes a lot of sense.  Packet filters that are
> broken can be fixed easily enough.  Even in the case of binary
> code, a few small hacks into an ELF file should fix things up.
> 
> Regardless of the official tree, I think I'm going to change mine
> to use the above ranges you listed simply because I've also
> encountered problems with ports being in use as well.
> 
	Yes, luckily it's a minor issue which can be easily fixed in the
source or with sysctl. I was just surprised to see that Linux was not
compliant on this point, especially because it can generate buggy behaviour
for applications.

	Regards,

	Bastiaan Bakker