Bug 17181

Summary:	UDP random port number not incremented
Product:	[Retired] Red Hat Linux	Reporter:	jkrzyszt
Component:	kernel	Assignee:	David Miller <davem>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-09-01 20:35:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jkrzyszt 2000-09-01 15:54:45 UTC

All processes opening UDP sockets in order to send data without prior
binding to a speciffic address get the same port number. It goes on until
an error occures during packet reception. After that, an ICMP message "port
xxx unreachable" is send, the random port number is incremeted by 1, and
the situation starts from the beginning.
I am not sure if it is a bug, or an implementation or design feature.
However, servers that receive these ICMP packets treat them as
communication errors an fill error logs with "connection refused" messages.

Comment 1 jkrzyszt 2000-09-01 16:02:35 UTC

BTW, kernel version numbers I have tesed are 2.2.16-3 and 2.2.16-4.lfs

Comment 2 jkrzyszt 2000-09-06 09:18:52 UTC

O.K, so maybe there is a bug in an application.

The application that suffers is "kprop" found in "krb5-server-1.1.1-21"
componnet. It opens a random UDP port and sends a packet to a "kpropd" daemon
listening on the well-known "krb5_prop" port on another machine. It usualy
happens that the answer received from that machine is rejected, and ICMP mesage
"port xxx unreachable" is sent. After that, "kprop" tries again, this time
selecting a random port that's number is higher by 1 than before, and it
succeedes.
However, netowork badwidth is unnecessarily consumed, as well as disk space on
the machine where kpropd error messages are logged.
Could you please reopen this bug, changing the component name to "krb5-server"?

Janusz