dynamic port allocation to processes

[support_5]

Hi, I have a rather abstract question: When HP-UX performs the Dynamic port allocation for processes connecting to a socket/port on another machine, how does it do this? Does it reserver a certain range of ports for use like this? Does it check that the port is not reserved in /etc/services? Does it know not to allocate ports less that 1024? etc. Any help in this would be appreciated. Thanks.


- Andrew Gray

[Ron Kinner · Accepted solution]

Would help if you would specify which version. Things changed at 10.30.

NDD (10.30 and later) offers several control parameters for this function tho not all are officially supported. You can set the lowest port and the highest port numbers for it to use for both tcp and udp connections and then it will randomly choose a port between the two bounds. Default is about 19K on the bottom and 64K on the top if I remember correctly.

Before the change the range was limited and the default was to choose port numbers in order tho you could use nettune to change this behavior at least by 10.0 with
tcp_random_seq. There was no control for the upper and lower bounds and they were fairly low below 6000 but above 1024.

Ron

[Ron Kinner]

And no it doesn't really care what it is in /etc/services.

Ron

[James R. Ferguson]

Hi Andrew:

Entities in /etc/services represent an "intention". The code creating a socket connection can specifically 'bind' to a particular port number or can bind to port zero (0). In this later cas, an available port is picked from the "anonymous" range of numbers. Starting with 10.30 this range, by default, is 49152 to 65535. Prior to this the range was 1024-5000.

The maximum anonymous port number can be limited via 'ndd' by setting 'tcp_largest_anon_port' and 'udp_largest_anon_port'

The so-called "well-known-ports" fall into the range below 1024 and cannot be bound unless the effective uid of the process is root's.

RFC 1700 enumerates port numbers. See here, for instance, for more information:

http://community.roxen.com/developers/idocs/rfc/rfc1700.html

Regards!

...JRF...

[support_5]

Thanks for the responses. It was for HP-UX 11.00, sorry. Okay, so that makes more sense what you have already said.

Thanks again.

- Andy Gray

[James R. Ferguson]

Hi (again) Andrew:

I was bothered by some of the details I found in RFC 1700 and so did a bit more digging. It turns out that RFC 3232 supersedes RFC 1700. In part, RFC 3232 reads, "Since 1994, this sequence of RFCs have been replaced by an online database accessible through a web page (currently, www.iana.org). The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 is obsolete, and its values are incomplete and in some cases may be wrong."

Thus, see:

http://www.iana.org/numbers.html

In part, this URL states:

Note that The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports. This file contains the listing of all registered port numbers.

The System (Well-Known) Ports are those from 0 through 1023.

The User (Registered) Ports are those from 1024 through 49151.

The Dynamic and/or Private Ports are those from 49152 through 65535.

Regards!

...JRF...

[support_5]

Hmmm, another question:

We have oracle databases running on an N4000 and the databases apparently use some ports in the range of 30000 to 55000. Now, what happens when a port required by an oracle server is actually in use by another program, eg a telnet or ssh process or even another oracle process (they would have recieved a random port number, right?)? Does HP-UX dynamically, and on the fly, re-assign the dynamic port number of the process to a different unused port when a process is wanting to bind to a particular port number? Or does it simply spit an error back to the oracle server process saying that the port is in use? Or just what happens here?

Thanks again,

- Andrew Gray

[James R. Ferguson]

Hi Andrew:

The use of bind{} with a port number of zero permits the system to pick an unused port. If a discrete port value is offered to bind() and that port number is already represented as an active socket (connection) then the bind() fails with an already inuse error.

Regards!

...JRF...

[support_5]

Okay, here is another one:

From what has been said above, does that mean that you should not configure applications to listen on ports in the private/random range of 49k-64k? And if they already do listen on that port, to change the application/database so that it doesn't?

yeah?

- Andy Gray