current stable makes vmware 5.5 and 6 sad, cries something about something not being implemented, so it may in fact be a vmware bug, but since dhcpcd-3.1.4 fixed the problem here, it may be a nice idea to stabilize that version
*** Bug 189107 has been marked as a duplicate of this bug. ***
3.1 versions prior to 3.1.5 had 3 potential buffer overflows. New target stable is 3.1.5 on 2007/09/21
(In reply to comment #2) > 3.1 versions prior to 3.1.5 had 3 potential buffer overflows. New target stable > is 3.1.5 on 2007/09/21 > I just correct the date. It should be 2007/08/21 because dhcpcd-3.1.5 has been released in August 21, 2007.
August 21 is today, dhcpcd-3.1.5 went in the tree 4 hours ago, target date is 2007/09/21.
adding archs, go for it
Stable for HPPA.
ppc64 done
mips stable.
stable on ppc
x86 stable
Tested net-misc/dhcpcd-3.1.5 USE="-vram" on SPARC. No bugs found. Portage 2.1.3.9 (default-linux/sparc/sparc64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-l7-r5 sparc64) ================================================================= System uname: 2.6.22-gentoo-l7-r5 sparc64 sun4u Timestamp of tree: Fri, 28 Sep 2007 03:20:01 +0000 app-shells/bash: 3.2_p17 dev-lang/python: 2.4.4-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="sparc" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /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" CXXFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O2 -pipe" DISTDIR="/exports/distfiles" FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.inode.at/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://mirror.muntinternet.net/pub/gentoo/ http://gentoo.ynet.sk/pub" LANG="en_US.UTF-8" LINGUAS="en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="64bit 7zip a52 ace adns alsa berkdb big-tables bzip2 caps cgi chroot clamav clamd cli courier crypt ctype custom-cflags cvs divx dnsdb doc dvd dynamic elf examples exim exiscan exiscan-acl extensions extraengine fast fastcgi fat flac gd ggi gif gzip hacking hddtemp highlight hpn httpd image imagemagick imap ipv6 ithreads jpeg jpeg2k l7filter lighttpd live logrotate maildir max-idx-128 mp3 mp4live mpeg multiuser mysql mysqli ncurses net netserver network network-cron networking nls nonfsv4 noudev nowin nptl nptlonly ogg pcre php png posix readline rtsp sasl screen scsi server session snmp spamassassin sparc spf ssl stream subversion suhosin svn-mirror symlink syslog szip test threads threadsafe threadsonly tiff unicode utf8 vcd vidix vim vim-syntax vnc vorbis web x264 xml zip zlib" ALSA_CARDS="CS4231" ALSA_PCM_PLUGINS="adpcm alaw copy dshare dsnoop extplug file hooks ladspa lfloat linear meter mulaw multi null rate route share shm" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="sunffb" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
alpha/ia64/sparc stable, thanks Friedrich and Tobias
Uhuhh, after upgrading to 3.1.5 (now stable on x86) I get -------------------------------------------------------------------- Sep 30 03:28:13 solarfire dhcpcd[7057]: eth0: dhcpcd 3.1.5 starting Sep 30 03:28:13 solarfire dhcpcd[7057]: eth0: hardware address = 00:16:d3:30:a5:21 Sep 30 03:28:13 solarfire dhcpcd[7057]: eth0: DUID = 00:01:00:01:0e:91:5e:6a:00:16:d3:30:a5:21 Sep 30 03:28:13 solarfire dhcpcd[7057]: eth0: broadcasting for a lease Sep 30 03:28:19 solarfire dhcpcd[7057]: eth0: offered 192.168.242.4 from 192.168.242.254 `wormhole' Sep 30 03:28:19 solarfire dhcpcd[7057]: eth0: received NAK: (null) Sep 30 03:28:19 solarfire dhcpcd[7057]: eth0: broadcasting for a lease ... -------------------------------------------------------------------- After falling back to 3.0.16-r1 everything is back to normal -------------------------------------------------------------------- Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: dhcpcd 3.0.16 starting Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: hardware address = 00:16:d3:30:a5:21 Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: broadcasting for a lease Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: offered 192.168.242.3 from 192.168.242.254 `wormhole' Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: leased 192.168.242.3 for 259200 seconds Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: adding IP address 192.168.242.3/24 Sep 30 03:42:00 solarfire dhcpcd[11796]: eth0: adding default route via 192.168.242.254 metric 0 -------------------------------------------------------------------- Note that I've got a reservation for this particaular MAC, i. e. 192.168.242.3 is the ip address that is assigned to my client. The DHCP server I'm using (for quite some time ...) is the one that's integrated into my zyxel/arcor DSL router. Further details to follow (on request). For now I've masked 3.1.5. We might have a regression here? Has this been tested with reservations? Cheers, Axel
OK, the problem disappears, when I add "vram" to package.use: net-misc/dhcpcd, i. e. if DUID's are not used. It is possible -- of course -- that my DHCP server doesn't behave properly, but I think it would be better, if the DUID feature would _not_ be enabled by _default_ Axel
(In reply to comment #14) > It is possible -- of course -- that my DHCP server doesn't behave properly, > but I think it would be better, if the DUID feature would _not_ be enabled > by _default_ However, DUID is required for firewire and infiniband devices. If you were dhcpcd maintainer, would you default to supporting more devices or DHCP servers who don't follow the RFC's? I chose the latter. You can also use dhcpcd_eth0="-I ''" in /etc/conf.d/net to turn it off also.
For other issues, please create new bugs as incorrectly configured DHCP servers should not stop dhcpcd-3.1 going stable. Thanks
(In reply to comment #16) > For other issues, please create new bugs as incorrectly configured DHCP servers > should not stop dhcpcd-3.1 going stable. Thanks Please note that the current dhcpcd does not work with Microsoft DHCP server also (same issue and your suggested workaround fixes it). There should be some clarification from your side in which respect these DHCP servers "don't follow the RFC's" or are "incorrectly configured".
(In reply to comment #17) > Please note that the current dhcpcd does not work with Microsoft DHCP server > also (same issue and your suggested workaround fixes it). There should be some > clarification from your side in which respect these DHCP servers "don't follow > the RFC's" or are "incorrectly configured". It works fine with the default configuration in Windows Advanced Server 2003, which I just tested. Again, ANY DHCP server configuration that relies on the MAC address being in the ClientID is faulty. The keyword is *configuration*.
I've also had to mask >=3.1 because of the Windows DHCP Server problem. Without AT LEAST some documentation, I consider the current dhcpcd unstable, regardless of what end the error is on.
(In reply to comment #19) > I've also had to mask >=3.1 because of the Windows DHCP Server problem. Without > AT LEAST some documentation, I consider the current dhcpcd unstable, regardless > of what end the error is on. It's documented in the ebuild. It's documented in the man page. It's documented in the source code. The default configuration of dhcpcd works with the default configuration for the following DHCP servers dnsmasq-2.3x ISC dhcp-3.x MS Win2k3 And whatever dhcp server is in a draytek vigor ADSL modem which I have handy. Until you - or anyone else - can prove otherwise, with a decent DHCP server config that causes this "error" then I see no reason to mark 3.1 as unstable. Judging by the whole number of people on this bug with the problem (all 2 of you) then I really think you're over reacting.
