dhcpcd specifies strange routes like '10.0.0.1 dev eth0 scope link', without 'via' field, for DHCP routes to single server (in this demo - dhcp route record is '10.0.0.1/32 192.160.0.254'). Windows DHCP clients receive routes normally. Reproducible: Always Steps to Reproduce: 1. Setup DHCP server on another PC 2. Add route to host with 10.0.0.1/32 subnet via gateway 192.168.0.254 (for ex.) to it's config 3. Try to get IP address and routes 4. Do 'ip r' Actual Results: '10.0.0.1 dev eth0 scope link' Expected Results: '10.0.0.1/32 via 192.168.0.254 dev eth0' # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r7 i686) ================================================================= System uname: 2.6.25-gentoo-r7 i686 AMD Athlon(tm) XP 2500+ Timestamp of tree: Sat, 27 Sep 2008 20:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ ftp://de-mirror.org/distro/gentoo/ http://mirror.jamit.de/gentoo/ http://mirror.netcologne.de/gentoo/ ftp://mirror.netcologne.de/gentoo/ " LANG="en_US.UTF-8" LC_ALL="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl apache2 berkdb cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mudflap mysql ncurses nls nptl nptlonly openmp pam pcre perl php pppd python readline reflection session spl ssl tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon 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 deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Please attach a full tcpdump or wireshark trace of the dhcp transaction. Also, dhcpcd-4.0.1-r1 has just gone stable on x86, so re-sync, upgrade and try that version.
I just tested this dhcpcd recorded 10.0.0.1/32 10.73.1.1 and added 10.0.0.1 via 10.73.1.1 dev re0 metric 202 So I guess it's fixed in dhcpcd-4.0.1 and this bug can be closed if reporter confirms
> So I guess it's fixed in dhcpcd-4.0.1 and this bug can be closed if reporter > confirms Yes, with 4.0.1 all is OK.
