I've recently discovered weird problems with 2.0.5-r1 (which is quite old now) and various (office) routers in the case that a previous IP (assigned by a DHCP server from a different net) has been cached. (roadwarrior scenario) With my zyxel DSL-Router (P660H-HW-W_T) I get: gentoo: DHCP Request (old-ip) zyxel: DHCP ACK (new-ip, new-defaultroute, new-dns, ..) which results in gentoo (dhcpcd-2.0.5-r1) assuming that it received an acknowledge for old-ip and configuring the interface as ip = old-ip, broadcast = new-broadcast With a wachguard firebox at my company's office I get a similar behaviour, i. e. new-ip is correctly assigned, but a few moments later gentoo/dhcpcd falls back to the original address. I haven't traced down the second case with wireshark yet, but I assume that watchguard sends an offer for new-ip which results in new-ip for a short period of time and then an acknowledge which triggers the "fallback" to old-ip In both cases deleting /var/lib/dhcpc/dhcpcd-eth0* before running dhcpcd (or /etc/init.d/net.eth0 restart) again solves the problem. But in both cases updating dhcpcd to 3.0.11 _also_ solves the problem. Maybe because the cache is no longer used and dhcpcd _always_ "discovers" first, i. e. behaves like no address has been assigned before. I've successfully tested 3.0.11 on x86 (after updating world) using the following network adapters/drivers - intel e1000 - broadcom tg3 - ipw2200 (using WPA/wpa_supplicant) - ipw3945 (using WPA/wpa_supplicant) and my zyxel DSL-router. I hope -- I pretty much expect so -- that the problem with the watchguard DHCP server is also solved by the update. Cheers Axel P.S.: It is possible that the problem occured for the first time when I started to use "ifplugd", i. e. when the interface is UP but not configured when "dhcpcd" is launched.
Need to give it a little more time. Packages should be in the tree for 30 days before being stabled, and dhcpcd-3 is still missing the mips keyword :/
3.0.14 fixes a crash on 0 or invalid length dhcp options, so we need more time I'm afraid.
3.0.14 didn't like MTU options.
I've recently updated my dhcpcd-3.0.10 to dhcpcd-3.0.15 and I have following problem: When I start dhcpcd I get: # /etc/init.d/net.eth0 start * Starting eth0 * Bringing up eth0 * dhcp * Running dhcpcd ... Error, eth0: minimum legal MTU is 68 [ ok ] * eth0 received address 10.0.0.4/8 With debugging turned on: # dhcpcd eth0 -d Info, eth0: dhcpcd 3.0.15 starting Info, eth0: hardware address = _my_mac_address_ Info, eth0: broadcasting for a lease Debug, eth0: sending DHCP_DISCOVER with xid 1898480185 Debug, eth0: waiting on select for 20 seconds Debug, eth0: got a packet with xid 1898480185 Debug, eth0: no facility to parse DHCP code 52 Info, eth0: offered 10.0.0.4 from 10.0.0.2 `�' Debug, eth0: sending DHCP_REQUEST with xid 1898480185 Debug, eth0: waiting on select for 20 seconds Debug, eth0: got a packet with xid 1898480185 Debug, eth0: no facility to parse DHCP code 52 Error, eth0: minimum legal MTU is 68 Info, eth0: leased 10.0.0.4 for 86400 seconds Info, eth0: no renewal time supplied, assuming 43200 seconds Info, eth0: no rebind time supplied, assuming 75600 seconds Debug, eth0: setting MTU to 68 Info, eth0: adding IP address 10.0.0.4/8 Info, eth0: adding default route via 10.0.0.2 metric 0 Debug, eth0: writing /etc/resolv.conf Debug, eth0: writing /var/lib/dhcpcd/dhcpcd-eth0.info Debug, eth0: forking to background # ifconfig eth0 Link encap:Ethernet HWaddr _my_mac_address_ inet addr:10.0.0.4 Bcast:255.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:68 Metric:1 RX packets:3925 errors:0 dropped:0 overruns:0 frame:0 TX packets:4373 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:587800 (574.0 Kb) TX bytes:805793 (786.9 Kb) I can ping my router: # ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.879 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.758 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.906 ms 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.760 ms --- 10.0.0.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 0.758/0.825/0.906/0.076 ms However, Internet doesn't work. Changing MTU to 1492 solves the problem: # ifconfig eth0 mtu 1492 Here is content of dhcpcd-eth0.info file: # cat /var/lib/dhcpcd/dhcpcd-eth0.info IPADDR='10.0.0.4' NETMASK='255.0.0.0' BROADCAST='255.255.255.255' MTU='68' ROUTES='0.0.0.0,0.0.0.0,10.0.0.2' DNSSERVERS='10.0.0.2' DHCPSID='10.0.0.2' DHCPSNAME='�' LEASETIME='86400' RENEWALTIME='43200' REBINDTIME='75600' INTERFACE='eth0' CLASSID='dhcpcd 3.0.15' CLIENTID='_my_mac_address_' DHCPCHADDR='_my_mac_address_' When I stop dhcpcd without setting MTU to 1492 and start it again, I get error "Message too long".
Please create a new bug for that and state dhcp server, version and configured options. Thanks
sigh
Go for it arch teams!
sparc stable.
Stable for HPPA.
x86 + ia64 stable
Hi, just out of curiosity ... What do these "stable on arch" messages imply? - marked stable in CVS? ==> sparc and HPPA are, x86 and ia64 are not - (likely to be) marked stable on the mirrors? Cheers Axel
(In reply to comment #11) > What do these "stable on arch" messages imply? That the arch teams have tested tested a specific version and found it to be stable to their satisfaction on their CPU architecture. Code for x86 (ie pentiums, athlons) doesn't always work on say sparc64. http://devmanual.gentoo.org/keywording/
Yeah, thanks! I think I understand this ~arch/arch thing in general. What I was refering to is the underlying workflow, i. e. if a developers posts "stable on ..." to bugzilla, does this mean that -- beside of a successful test -- the ebuild in CVS has also been updated? Or in other words: How much time later can "emerge --sync" to be expected to reflect the change? I know that this discussion is quite "off topic", but I would like to close the bug which I can't as long as 3.0.16 isn't stable on the mirrors ... Thanks and sorry for being "off topic" Axel P. S.: Just noticed that x86 and ia64 are now also stable in CVS
(In reply to comment #13) > What I was refering to is the underlying workflow, i. e. > > if a developers posts "stable on ..." to bugzilla, > does this mean that -- beside of a successful test -- > the ebuild in CVS has also been updated? Yes > > Or in other words: > > How much time later can "emerge --sync" to be expected to reflect the change? About 1-2 hours normally. And you don't close this bug, we do :) Thanks
OK, no more questions left open ... ... and time to thank you guys at gentoo for your excellent work! I'm really enjoying to work with it and I hope that you'll never give up on it -- regardless of whatever discord may sometimes arise in the user and/or developer community. Axel :-)
ppc stable
emerges fine and works on amd64 Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.20-beyond2 x86_64) ================================================================= System uname: 2.6.20-beyond2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 05 Apr 2007 13:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -msse3 -w" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe -msse3 -w" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet" FEATURES="buildsyspkg ccache collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ " LANG="en_US.ISO8859-15" LC_ALL="en_US.ISO8859-15" MAKEOPTS="-j3 -l3 -s --no-print-directory" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" 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="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acpi alsa amd64 amr audiofile berkdb bitmap-fonts bzip2 cairo cdinstall cdr cli cracklib crypt cups dbus dri dts dvd dvdr dvdread emboss encode fam firefox fortran gdbm gif gpm gstreamer gtk gtk2 hal iconv jpeg libg++ logrotate mad midi mikmod mp3 mpeg ncurses nptl nptlonly offensive ogg opengl pam pcre php png ppds pppd quicktime readline reflection sdl session smp spl ssl svg symlink tcpd test tiff truetype truetype-fonts type1-fonts unicode v4l vim vorbis x264 xinerama xorg xv xvid zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="inputlirc" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
amd64 stable
ppc64 stable
Mark -r1 stable instead as it needed a patch for crappy DHCP servers that stupidly think they need to respect the mininum BOOTP message size of 300 bytes that seem to be in cheap SOHO routers.
Stable on MIPS.
(In reply to comment #4) > I've recently updated my dhcpcd-3.0.10 to dhcpcd-3.0.15 and I have following > problem: > When I start dhcpcd I get: > > # /etc/init.d/net.eth0 start > * Starting eth0 > * Bringing up eth0 > * dhcp > * Running dhcpcd ... > Error, eth0: minimum legal MTU is 68 [ ok ] > * eth0 received address 10.0.0.4/8 > > With debugging turned on: > > # dhcpcd eth0 -d > Info, eth0: dhcpcd 3.0.15 starting > Info, eth0: hardware address = _my_mac_address_ > Info, eth0: broadcasting for a lease > Debug, eth0: sending DHCP_DISCOVER with xid 1898480185 > Debug, eth0: waiting on select for 20 seconds > Debug, eth0: got a packet with xid 1898480185 > Debug, eth0: no facility to parse DHCP code 52 > Info, eth0: offered 10.0.0.4 from 10.0.0.2 `�' > Debug, eth0: sending DHCP_REQUEST with xid 1898480185 > Debug, eth0: waiting on select for 20 seconds > Debug, eth0: got a packet with xid 1898480185 > Debug, eth0: no facility to parse DHCP code 52 > Error, eth0: minimum legal MTU is 68 > Info, eth0: leased 10.0.0.4 for 86400 seconds > Info, eth0: no renewal time supplied, assuming 43200 seconds > Info, eth0: no rebind time supplied, assuming 75600 seconds > Debug, eth0: setting MTU to 68 > Info, eth0: adding IP address 10.0.0.4/8 > Info, eth0: adding default route via 10.0.0.2 metric 0 > Debug, eth0: writing /etc/resolv.conf > Debug, eth0: writing /var/lib/dhcpcd/dhcpcd-eth0.info > Debug, eth0: forking to background > > # ifconfig > eth0 Link encap:Ethernet HWaddr _my_mac_address_ > inet addr:10.0.0.4 Bcast:255.255.255.255 Mask:255.0.0.0 > UP BROADCAST RUNNING MULTICAST MTU:68 Metric:1 > RX packets:3925 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4373 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:587800 (574.0 Kb) TX bytes:805793 (786.9 Kb) > > I can ping my router: > > # ping 10.0.0.2 > PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.879 ms > 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.758 ms > 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.906 ms > 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.760 ms > > --- 10.0.0.2 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3002ms > rtt min/avg/max/mdev = 0.758/0.825/0.906/0.076 ms > > However, Internet doesn't work. > > Changing MTU to 1492 solves the problem: > > # ifconfig eth0 mtu 1492 > > Here is content of dhcpcd-eth0.info file: > > # cat /var/lib/dhcpcd/dhcpcd-eth0.info > IPADDR='10.0.0.4' > NETMASK='255.0.0.0' > BROADCAST='255.255.255.255' > MTU='68' > ROUTES='0.0.0.0,0.0.0.0,10.0.0.2' > DNSSERVERS='10.0.0.2' > DHCPSID='10.0.0.2' > DHCPSNAME='�' > LEASETIME='86400' > RENEWALTIME='43200' > REBINDTIME='75600' > INTERFACE='eth0' > CLASSID='dhcpcd 3.0.15' > CLIENTID='_my_mac_address_' > DHCPCHADDR='_my_mac_address_' > > When I stop dhcpcd without setting MTU to 1492 and start it again, I get error > "Message too long". > Quite the same problem here. With dhcpcd 3.0.16-r1 I get an mtu too low (64) by the provider. Using dhclient from net-misc/dhcp I get the usual 1500 one :) Cheers!
Stop creating noise on this bug please. The MTU is being set by your buggy router. dhcpcd-3.0.17 now ignores values lower than 576 instead of setting 576 when it's too low.
alpha stable, thanks Tobias.
