Linux RedHat 6.x bug: IPv4/UDP bind() allocates same port number by default

Linux RedHat 6.x bug: IPv4/UDP bind() allocates same port number by default

Post by Dan Kege » Wed, 17 Nov 1999 04:00:00



Does anyone know of a standard that specifies the behavior
of bind() when assigning ephemeral UDP port numbers?
It seems that Linux keeps giving out the same port number
over and over again if it's free, but other Unixes increment
the port number.  

"Unix Network Programming", vol 1, 2nd ed doesn't seem to specify
this, nor does the Single Unix Specification v2.

Having written user-mode connection-oriented
UDP stuff myself, I know that this would be annoying.
When you kill and restart a program, the other side can notice
you have the wrong sequence number, and do a reset, but that's
hard to debug; it's safer to use a different port number for
each instance of the program.
And if ephemeral port numbers are assigned to make that easy
under most Unixes, Linux probably ought to behave that way, too.
- Dan

In http://kernelnotes.org/lnxlists/linux-kernel/lk_9911_02/msg00964.html


>  When dynamically binding a new UDP socket to a port, the bind()
>  system usually returns the same value, and this confuses remote
>  UDP servers for a few minutes timeouts.
>  The reason is that the next eligible value used is the last
>  allocated value (if freed) and not the next one.
>  Urgency: HIGH because may affect portability and interoperbility
>  of applications using UDP protocol.
> [test program, data showing problem only on Linux, and
> patch fixing the problem deleted]

> [the affected software is an] RPC package developped at CERN ...
> Due to control system evolution this had to be ported to a large
> number of platforms (Vax/VMS, Appolo, HP/UX, Ultrix, OSF/1, Solaris,
> AIX, Xenix, OS/9, LynxOS, ...) and is currently used without any
> problem for most communications between several hundred front-end systems
> and around same number of Unix workstations ...

> I am currently evaluating if Linux might be used as a replacement
> of around 100 AIX systems used as operator's interface to the
> CERN particule accelerators.

> This RPC package has a transport layer built on top of UDP which
> identifies transactions by (source IP, port number, sequence number).
> In case of very low activity on the system, only Linux allocates
> twice the same port number for an UDP port as result of bind(0)
> within a very short amount of time. As the protocol is running
> at user level, the 1rst sequence number allocated is always 0
> when you start a client task and therefore all message sent are
> considered as repetitions of previous transactions that might
> still need for an extra repetition of the non-acknowleged messages.

> I can turn around this problem specifically under Linux, (binding
> two sockets instead of a single one to force the counter to increment).
> But the encountered problem (same port number, same sequence number,
> ...) which leads to a reject of the call might be encountered by any
> RPC system or even by tftp, especially when some routers are in
> a chain.

> There is a good reason for all other OS to avoid to give back
> the same port number for a while, in a round-robin manner and
> the fact that only Linux does not might lead to unpredictable
> problems very difficult to diagnose.

> After 20 years of system software support - having already lost
> enough time during the last 20 years to debug network device
> drivers and applications - I recommend to change quickly this bad
> Linux behaviour in order to conform to all other TCP/IP
> implementations - this especially to avoid that other people
> loose their time.

--
(The above is just my personal opinion; I don't speak for my employer,
 except on the occasional talk show.)
 
 
 

Linux RedHat 6.x bug: IPv4/UDP bind() allocates same port number by default

Post by Dan Kege » Wed, 17 Nov 1999 04:00:00


Does anyone know of a standard that specifies the behavior
of bind() when assigning ephemeral UDP port numbers?
It seems that Linux keeps giving out the same port number
over and over again if it's free, but other Unixes increment
the port number.  

"Unix Network Programming", vol 1, 2nd ed doesn't seem to specify
this, nor does the Single Unix Specification v2.

Having written user-mode connection-oriented
UDP stuff myself, I know that this would be annoying.
When you kill and restart a program, the other side can notice
you have the wrong sequence number, and do a reset, but that's
hard to debug; it's safer to use a different port number for
each instance of the program.
And if ephemeral port numbers are assigned to make that easy
under most Unixes, Linux probably ought to behave that way, too.
- Dan

In http://kernelnotes.org/lnxlists/linux-kernel/lk_9911_02/msg00964.html


>  When dynamically binding a new UDP socket to a port, the bind()
>  system usually returns the same value, and this confuses remote
>  UDP servers for a few minutes timeouts.
>  The reason is that the next eligible value used is the last
>  allocated value (if freed) and not the next one.
>  Urgency: HIGH because may affect portability and interoperbility
>  of applications using UDP protocol.
> [test program, data showing problem only on Linux, and
> patch fixing the problem deleted]

> [the affected software is an] RPC package developped at CERN ...
> Due to control system evolution this had to be ported to a large
> number of platforms (Vax/VMS, Appolo, HP/UX, Ultrix, OSF/1, Solaris,
> AIX, Xenix, OS/9, LynxOS, ...) and is currently used without any
> problem for most communications between several hundred front-end systems
> and around same number of Unix workstations ...

> I am currently evaluating if Linux might be used as a replacement
> of around 100 AIX systems used as operator's interface to the
> CERN particule accelerators.

> This RPC package has a transport layer built on top of UDP which
> identifies transactions by (source IP, port number, sequence number).
> In case of very low activity on the system, only Linux allocates
> twice the same port number for an UDP port as result of bind(0)
> within a very short amount of time. As the protocol is running
> at user level, the 1rst sequence number allocated is always 0
> when you start a client task and therefore all message sent are
> considered as repetitions of previous transactions that might
> still need for an extra repetition of the non-acknowleged messages.

> I can turn around this problem specifically under Linux, (binding
> two sockets instead of a single one to force the counter to increment).
> But the encountered problem (same port number, same sequence number,
> ...) which leads to a reject of the call might be encountered by any
> RPC system or even by tftp, especially when some routers are in
> a chain.

> There is a good reason for all other OS to avoid to give back
> the same port number for a while, in a round-robin manner and
> the fact that only Linux does not might lead to unpredictable
> problems very difficult to diagnose.

> After 20 years of system software support - having already lost
> enough time during the last 20 years to debug network device
> drivers and applications - I recommend to change quickly this bad
> Linux behaviour in order to conform to all other TCP/IP
> implementations - this especially to avoid that other people
> loose their time.

--
(The above is just my personal opinion; I don't speak for my employer,
 except on the occasional talk show.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Please read the FAQ at http://www.tux.org/lkml/

 
 
 

Linux RedHat 6.x bug: IPv4/UDP bind() allocates same port number by default

Post by Stuart Friedbe » Thu, 18 Nov 1999 04:00:00




Quote:>Does anyone know of a standard that specifies the behavior
>of bind() when assigning ephemeral UDP port numbers?

There is none, and you should make NO assumptions about what any given
host might do beyond keeping the 4-tuple of fport-fhost-lport-lhost
unique for TCP.  Since UDP is seldom used in a "connected" state and
even that much is a implementation specific option, not a
standard-defined behavior, assume nothing for UDP.

The ancestral BSD implementation increments the port number.  Other
implementations try harder to conserve port number space.  In at least
one case, the algorithm used to allow more than 64K concurrent TCP
connections is applied to UDP as well, even though UDP doesn't have the
same problem of exhausting the lport number space.

Quote:>And if ephemeral port numbers are assigned to make that easy
>under most Unixes, Linux probably ought to behave that way, too.

Ephemeral port numbers were (traditionally) assigned that way because
it was a trivial implementation, not to make it easier to debug your
programs.  I agree that stepping through the port number space has
some advantages.  But AFAIK there is no standard addressing this.


 
 
 

Linux RedHat 6.x bug: IPv4/UDP bind() allocates same port number by default

Post by Alun Jon » Thu, 18 Nov 1999 04:00:00





> >And if ephemeral port numbers are assigned to make that easy
> >under most Unixes, Linux probably ought to behave that way, too.

> Ephemeral port numbers were (traditionally) assigned that way because
> it was a trivial implementation, not to make it easier to debug your
> programs.  I agree that stepping through the port number space has
> some advantages.  But AFAIK there is no standard addressing this.

I might note that there are reasons not to assign ephemeral port numbers in
an easily guessable way - whether this is "reuse ASAP" or "increase by N
each time", there are attacks that rely on being able to guess what
ephemeral port will be provided next.

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email

Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*