I just encounted an issue where Linux with dhcpcd was booted on a network with more than 1 dhcp server and when dhcpcd ran it went into a loop of accepting an ip address from one dhcp server, but then accepting a NAK from the other dhcp server. It did this about 30 times and then exited. I haven't tested on a second network yet, but I can do if you need me to before this can be confirmed as a bug. Reproducible: Didn't try Steps to Reproduce: 1. Setup two authoritative dhcp servers on the same network 2. Load dhcpcd on the network Actual Results: dhcpcd log: dhcpcd[4304]: net0: soliciting a DHCP lease dhcpcd[4304]: net0: offered 192.168.0.48 from 192.168.0.2 dhcpcd[4304]: net0: ignoring offer of 192.168.0.124 from 192.168.0.201 dhcpcd[4304]: net0: NAK: from 192.168.0.201 dhcpcd[4304]: net0: soliciting a DHCP lease dhcpcd[4304]: net0: offered 192.168.0.48 from 192.168.0.2 dhcpcd[4304]: net0: ignoring offer of 192.168.0.124 from 192.168.0.201 dhcpcd[4304]: net0: NAK: from 192.168.0.201 Expected Results: dhcpcd should have accepted an ip address from one of the servers and stayed on that one. Portage 2.2.8-r2 (hardened/linux/amd64, gcc-4.8.3, glibc-2.19-r1, 3.14.25-hardened-r1 x86_64) ================================================================= System uname: Linux-3.14.25-hardened-r1-x86_64-Intel-R-_Core-TM-_i7-4790_CPU_@_3.60GHz-with-gentoo-2.2 KiB Mem: 16345076 total, 15857112 free KiB Swap: 2095100 total, 2095100 free Timestamp of tree: Tue, 25 Nov 2014 14:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p53 dev-lang/perl: 5.18.2-r2 dev-lang/python: 2.7.7, 3.3.5-r1, 3.4.1 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13::<unknown repository>, 2.69 sys-devel/automake: 1.4_p6::<unknown repository>, 1.5::<unknown repository>, 1.6.3::<unknown repository>, 1.7.9-r1::<unknown repository>, 1.8.5-r3::<unknown repository>, 1.9.6-r2::<unknown repository>, 1.10.3-r1, 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.6.3, 4.8.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo x-portage ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -mtune=amdfam10 -fomit-frame-pointer -ftree-vectorize -fpredictive-commoning -fno-tree-vect-loop-version" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -mtune=amdfam10 -fomit-frame-pointer -ftree-vectorize -fpredictive-commoning -fno-tree-vect-loop-version" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.internode.on.net/pub/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync/gentoo-portage" USE="acl acpi alsa amd64 apache2 berkdb bzip2 caps cjk cli cracklib crypt cups cxx dlloader dri fam gdbm hardened iconv ipv6 jpeg justify logrotate mmx mng modules multilib ncurses nls nptl openmp pam pax_kernel pcre png qt readline session sse sse2 ssl tcpd threads tiff unicode urandom vhosts xattr xinerama xtpax zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias cgid" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Sounds like dhcpcd is doing exactly what it should be doing according to RFC 2131[1] and RFC 3203[2]. You should probably fix your network (either of the DHCP servers or both) instead of trying to fix dhcpcd. Your whole problems seems to revolve around "[m]ore than 1 dhcp server on network". We have tools in net-analyzer/ to help you deal with that kind of situation. [1] "If the client receives a DHCPNAK message, the client restarts the configuration process." https://www.ietf.org/rfc/rfc2131.txt [2] "If the server wants to assign a new IP address to the client, it will reply to the DHCP REQUEST with a DHCP NAK. The client will then go back to the init state and broadcast a DHCP DISCOVER message." https://www.ietf.org/rfc/rfc3203
Okay thanks, The computer that was having the issue is a new Linux server intended to fix multiple issues on a remote pre-existing network and was initially configured in dhcp client mode to prevent conflicts with existing ip addresses, but due to the multiple dhcp servers (identified with tools like "nmap -sU -p 67 --script=dhcp-discover <target>), I've now configured it with a static ip address. Interestingly Windows doesn't seem to be affected by the multiple dhcp servers so I may look into that on a test network as well as test with ISC's dhclient sometime as this same NAK issue can also happen when a rogue authoritive server is placed on a network (public hotspot for example),
You could regard this as a bug with the DHCP specification. Most IPv4 implementations only have a single IPv4 address. All IPv6 implementations have to have >1 IPv6 address. As the storage of addresses on an interface tries to be protocol agnostic, when IPv6 was implemented, IPv4 grew the possibility to have >1 address. However, DHCP was not really updated in this regard and the way NAK is described is really only descriptive of the single address limitation. DHCPv6 has no NAK as such - instead each address requested is either allocated or denied, thus in your situation you would have 2 IPv6 addresses via DHCPv6 instead of the NAK loop as you see. dhcpcd is strictly RFC conformant, so the behaviour you describe is actually correct, as noted as well by Jeroen Roovers. But how do we move this forwards? We cannot just pick one and ignore the other, the spec won't allow it. Luckily, you can blacklist servers in dhcpcd.conf so that you don't see NAK addresses.
Per Roy's comment above, I am closing this as invalid since you can blacklist servers. If you feel there is more i can do, please feel free to comment or reopen.
