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