We were investigating a bug where a reserved UDP server port could not be opened in rare cases by the application. We determined that in the failure case, the dhclient process was holding the application's port udp/13820, preventing legitimate use by the intended application. See netstat excerpt below:

udp        0      0 0.0.0.0:68                  0.0.0.0:*                               0          8142       6362/dhclient 

udp   200192      0 0.0.0.0:13820               0.0.0.0:*                               0          8123       6362/dhclient  


Our investigation determined that this port was opened because of the NSUPDATE feature using the following call sequence:
output/out/work/mipsel-*/dhcp-4.3.2/client/dhclient.c:152 function main

output/out/work/mipsel-*/dhcp-4.3.2/omapip/isclib.c:235 function dhcp_context_create

dns_client_createx2
getudpdispatch
dns_dispatch_getudp
dns_dispatch_getudp_dup
dispatch_createudp

get_udpsocket


The get_udpsocket employs logic that attempts 1024 times to find a random unused port. In the failure case, it is selecting a port required for our application. See here: http://users.isc.org/~each/doxygen/bind9/dispatch_8c-source.html#l02865


It is unclear to me why get_udpsocket doesn't just use the Linux port number selection in the first place. However, if get_udpsocket needs to select its own local port number, then it should adhere to the ephemeral (temporary) port range specified in /proc/sys/net/ipv4/ip_local_port_range to avoid these kinds of conflicts.


Thanks,

--
Michael Overcash
Principal Engineer, Cisco SPVSS