I saw that for some weeks (possible monthes) periodically LAN connection is dropped. I look in logs and saw that trouble is by dhcpcd - it can't renew lease (as I understand, it can't send DHCP request - possible, bug of LAN driver, because on other PC with x86, 2.6.27-gentoo-r10 kernel and realtek 8139 all works OK), and it can't use old lease for unknown reason (this is bug of dhcpcd). Reproducible: Always Steps to Reproduce: 1. Install x86_64 OS, put i82550 LAN card, install 2.6.29-gentoo-r5 kernel and dhcpcd 2. Configure LAN card to get IP by dhcpcd 3. Wait for renewing lease Actual Results: Jul 8 10:10:44 NiTr0 dhcpcd[8436]: eth0: leased 192.168.192.131 for 86400 seconds Jul 8 22:10:44 NiTr0 dhcpcd[8436]: eth0: renewing lease of 192.168.1.1 Jul 8 22:10:44 NiTr0 dhcpcd[8436]: eth0: send_packet: Invalid argument Jul 8 22:10:45 NiTr0 dhcpcd[8436]: eth0: lost lease Jul 8 22:10:45 NiTr0 dhcpcd[8436]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jul 8 22:10:45 NiTr0 dhcpcd[8436]: eth0: probing for an IPV4LL address Jul 8 22:10:45 NiTr0 dhcpcd[8436]: eth0: checking 169.254.204.124 is available on attached networks Jul 8 22:10:51 NiTr0 dhcpcd[8436]: eth0: using IPv4LL address 169.254.204.124 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: broadcasting for a lease Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: offered 192.168.1.1 from 192.168.2.1 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: ignoring offer of 192.168.1.1 from 192.168.2.1 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: ignoring offer of 192.168.1.1 from 192.168.2.1 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: ignoring offer of 192.168.1.1 from 192.168.2.1 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: acknowledged 192.168.1.1 from 192.168.2.1 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: checking 192.168.1.1 is available on attached networks Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: wrong state 9 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: checking 192.168.1.1 is available on attached networks Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: wrong state 9 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: checking 192.168.1.1 is available on attached networks Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: wrong state 9 Jul 8 22:11:58 NiTr0 dhcpcd[8436]: eth0: checking 192.168.1.1 is available on attached networks Jul 8 22:12:03 NiTr0 dhcpcd[8436]: eth0: leased 192.168.1.1 for 86400 seconds Expected Results: Normal renewing or, if it is impossible, using old lease. # emerge --info Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.29-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.29-gentoo-r5-x86_64-AMD_Sempron-tm-_Processor_3000+-with-glibc2.2.5 Timestamp of tree: Sun, 05 Jul 2009 00:25:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.5.4-r2 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind /var/lib/hsqldb" 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/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://files.seti.kr.ua/mirrors/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://files.seti.kr.ua/gentoo-portage" USE="3dnow X acl acpi alsa amd64 apache2 apm berkdb bzip2 cdr cgi cli cracklib crypt cups dri encode fat fortran gd gdbm gpm hal iconv ipv6 isdnlog java jpeg jpeg2k midi mmx mp3 mudflap multilib mysql mysqli ncurses nls nptl nptlonly opengl openmp pam pcre perl php png pppd python qt readline reflection reiser4 reiserfs samba session slang spl sqlite sse sse2 ssl svg symlink sysfs taglib tcpd theora tiff unicode usb vnc wifi xfce xorg xulrunner zlib" 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" 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 evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="vesa nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS # lspci|grep Intel 02:07.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 0d)
Compare the kernel configs of the PC where dhcp works and the one that doesn't -- it sounds like you are missing CONFIG_PACKET in the one that can't dhcp
In problematic kernel CONFIG_PACKET=y DHCP works - but works strange, it has troubles only on renewing lease. Earlier all was OK - I look into logs, it seems that trouble appears 1 month ago, 15th Jun, after replacement of LAN card (rtl8139d->i82559), kernel was compiled earlier - 10th Jun. But still remains question - why DHCP don't use previous lease?
I've had the same thing ; same kernel (with CONFIG_PACKET=y), same dhcpcd, and every time it tried to renew a lease, the same "send_packet: Invalid argument" in the logs. The only difference is the driver, I don't use e100 but forcedeth. According to my logs, it happened after I booted on this new kernel, so I just restarted /etc/init.d/net.eth2, and the problem disappeared (unloading forcedeth hadn't change anything). Doesn't explain anything, but my connection doesn't falls anymore.
In my case the behavior reported by NiTr0 is triggered by permanent DHCP leases issued by my router. As soon as I switch to temporary leases I still get a warning about "wrong state 9" but I get an IP address. The warning appears only the first time when dhcpcd is restarted. Subsequent requests go without a hitch. As soon as I switch back to permanent leases on my router, dhcpcd fails to obtain/renew the IP address. I peeked at the communication with Wireshark and I see the following sequence (C: client S: DHCP server): C: DHCPDISCOVER S: DHCPOFFER C: DHCPREQUEST S: DHCPOFFER S: DHCPACK C: ARP broadcast for offered address (src: 0.0.0.0) S: DHCPNACK (broadcast, contains only client's MAC address) C: DHCPACK The whole sequence repeats itself until dhcpcd gives up If instead I run /sbin/dhcpcd -h zeus -N -Y -A eth0 (where I inserted -A into the original command-line) the sequence changes to C: DHCPDISCOVER S: DHCPOFFER C: DHCPREQUEST S: DHCPOFFER S: DHCPACK S: DHCPACK C: ARP broadcast for server IP address S: ARP reply to broadcast C: ICMP dst unreacheable (port 68 unreachable) S: DHCPNACK and I get my IP address. Also, dhcpcd seems happy; no errors or warnings despite the NACK. The dhcpcd process is running. I guess it just closes the port, which explains the ICMP dst unreachable message and why dhcpcd is not bothered by the NACK. When configuring my router to hand out temporary leases, the NACKs do not appear. This occurs with dhcpcd-4.13. I will try the 5.x series and see what happens.
dhcpcd-5.x appears to be hardmasked. Adding dhcpcd_eth0="-A" to /etc/conf/net solves my problem for the time being.
Hmm.. I missed up about e100 module - I set up e100 much earlier, uptime of PC is ~45 days. So I'll try to remember what I tried to install (possible - dhcpd to LAN on eth1 and tftpd here). Also I tried to restart net.eth0 - let's look on results. P.S. But why dhcpcd doesn't want to use old lease?
I'm having the same issue. It just started about a month ago after I rebuilt my laptop kernel: nc6220 log # uname -a Linux nc6220 2.6.29-gentoo-r5 #1 PREEMPT Thu Jun 11 20:14:41 EDT 2009 i686 Intel(R) Pentium(R) M processor 1.73GHz GenuineIntel GNU/Linux The NIC is: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express The version of DHCPCD is: nc6220 log # equery l dhcpcd [ Searching for package 'dhcpcd' in all categories among: ] * installed packages [I--] [ ] net-misc/dhcpcd-4.0.13 (0) Same exact symptoms as everyone else. The change for me was going from a 2.6.27 kernel to a 2.6.29 kernel. Might this be a bug in the kernel? I used the old config when I moved to the new kernel so it *should* be identical to the old kernel. Just adding my thoughts. I don't want to disable IPV4LL because I use Avahi for Pulseaudio.
Hmmm... After restarting net.eth0 all is OK. Strange...
Same issues here with x86, gentoo-sources-2.6.29-r5 and dhcpcd-4.0.13 A downgrade to dhcpcd-4.0.7 and anything works fine for me. emerge --info: http://nopaste.info/1ecd7fcf73.html Kernel config: http://nopaste.info/caea66cdaf.html Maybe it's helpful for you.
Same problem here, but it happened on a running system. Watching at the logs, it started after having lost the carrier on eth0 for a few seconds. ---------- Jul 22 08:07:36 izio dhcpcd[4441]: eth0: renewing lease of 39.254.4.39 Jul 22 08:07:36 izio dhcpcd[4441]: eth0: acknowledged 39.254.4.39 from 39.254.4.36 Jul 22 08:07:36 izio dhcpcd[4441]: eth0: leased 39.254.4.39 for 3600 seconds Jul 22 08:10:00 izio dhcpcd[4441]: eth0: carrier lost Jul 22 08:10:46 izio dhcpcd[4441]: eth0: carrier acquired Jul 22 08:10:46 izio dhcpcd[4441]: eth0: rebinding lease of 39.254.4.39 Jul 22 08:11:16 izio dhcpcd[4441]: eth0: failed to rebind Jul 22 08:11:16 izio dhcpcd[4441]: eth0: broadcasting for a lease Jul 22 08:12:19 izio dhcpcd[4441]: eth0: timed out Jul 22 08:12:19 izio dhcpcd[4441]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jul 22 08:12:19 izio dhcpcd[4441]: eth0: probing for an IPV4LL address Jul 22 08:12:19 izio dhcpcd[4441]: eth0: checking 169.254.35.183 is available on attached networks Jul 22 08:12:24 izio dhcpcd[4441]: eth0: using IPv4LL address 169.254.35.183 Jul 22 08:13:31 izio dhcpcd[4441]: eth0: broadcasting for a lease Jul 22 08:13:38 izio dhcpcd[4441]: eth0: carrier lost Jul 22 08:13:46 izio dhcpcd[4441]: eth0: carrier acquired Jul 22 08:13:46 izio dhcpcd[4441]: eth0: checking 169.254.35.183 is available on attached networks Jul 22 08:13:50 izio dhcpcd[4441]: eth0: using IPv4LL address 169.254.35.183 Jul 22 08:14:56 izio dhcpcd[4441]: eth0: carrier lost Jul 22 08:15:06 izio dhcpcd[4441]: eth0: carrier acquired Jul 22 08:15:06 izio dhcpcd[4441]: eth0: checking 169.254.35.183 is available on attached networks Jul 22 08:15:11 izio dhcpcd[4441]: eth0: using IPv4LL address 169.254.35.183 Jul 22 08:16:18 izio dhcpcd[4441]: eth0: broadcasting for a lease Jul 22 08:16:19 izio dhcpcd[4441]: eth0: offered 39.254.4.39 from 39.254.4.36 Jul 22 08:16:19 izio dhcpcd[4441]: eth0: acknowledged 39.254.4.39 from 39.254.4.36 Jul 22 08:16:19 izio dhcpcd[4441]: eth0: checking 39.254.4.39 is available on attached networks Jul 22 08:16:24 izio dhcpcd[4441]: eth0: leased 39.254.4.39 for 3600 seconds Jul 22 08:46:24 izio dhcpcd[4441]: eth0: renewing lease of 39.254.4.39 Jul 22 08:46:24 izio dhcpcd[4441]: eth0: send_packet: Invalid argument Jul 22 08:46:25 izio dhcpcd[4441]: eth0: lost lease Jul 22 08:46:25 izio dhcpcd[4441]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jul 22 08:46:25 izio dhcpcd[4441]: eth0: probing for an IPV4LL address Jul 22 08:46:25 izio dhcpcd[4441]: eth0: checking 169.254.140.150 is available on attached networks Jul 22 08:46:30 izio dhcpcd[4441]: eth0: using IPv4LL address 169.254.140.150 Jul 22 08:47:38 izio dhcpcd[4441]: eth0: broadcasting for a lease Jul 22 08:47:39 izio dhcpcd[4441]: eth0: offered 39.254.4.39 from 39.254.4.36 Jul 22 08:47:40 izio dhcpcd[4441]: eth0: acknowledged 39.254.4.39 from 39.254.4.36 Jul 22 08:47:40 izio dhcpcd[4441]: eth0: checking 39.254.4.39 is available on attached networks Jul 22 08:47:45 izio dhcpcd[4441]: eth0: leased 39.254.4.39 for 3600 seconds ---------- I can't be sure that the issue is connected to the lost carrier, because at the end dhcpcd successfully obtained the IP address, and the problem started on the next renewal. Restarting net.eth0 solved the problem. izio ~ # uname -a Linux izio 2.6.27-gentoo-r10-v5 #1 SMP Mon Apr 27 09:38:23 CEST 2009 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux izio ~ # lspci | grep Ethernet | grep Intel 02:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02) izio ~ # equery l dhcpcd [ Searching for package 'dhcpcd' in all categories among: ] * installed packages [I--] [ ] net-misc/dhcpcd-4.0.13 (0)
Confirm post #10 - for me it takes place again 2 days ago after carrier lost. After carrier lost lease is renewed normally, on next renew - I've got an error. After restarting net.eth0 - all is OK again.
Roy, could use some help to troubleshoot this one.
disable carrier detection for dhcpcd-4.x (-L) or upgrade to dhcpcd-5.x where this is fixed. The error is that the state engine for dhcpcd-4 is very very complicated and sometimes breaks like this. dhcpcd-5 has a much cleaner approach.
I have hit this bug too. The problem is described here: http://roy.marples.name/projects/dhcpcd/ticket/161 I believe it is fixed in newer versions of dhcpcd. I'm using 4.0.13. The problem starts after loss of carrier. dhcpcd switches to a IPv4LL address. Now all subsequent attempts to renew a lease fails with "send_packet: Invalid argument". Each time dhcpcd switches back to the IPv4LL address waits one minute and then broadcasts for and acquires a new lease from the dhcp server. The problem persists until dhcpcd is restarted. Thank you Roy for the hint about using -L. The manpage does however say: -K, --nolink Don't receive link messages for carrier status. -L, --noipv4ll Don't use IPv4LL (aka APIPA, aka Bonjour, aka ZeroConf). I'll try adding -K here and see what happens.
If this version known as buggy - why it is still in stable tree?
(In reply to comment #15) > If this version known as buggy - why it is still in stable tree? > Because it is the best there is and 5.x can't go stable until baselayout-2 is stable.
(In reply to comment #14) > I have hit this bug too. The problem is described here: > http://roy.marples.name/projects/dhcpcd/ticket/161 > > I believe it is fixed in newer versions of dhcpcd. I'm using 4.0.13. > > The problem starts after loss of carrier. dhcpcd switches to a IPv4LL address. > Now all subsequent attempts to renew a lease fails with "send_packet: Invalid > argument". Each time dhcpcd switches back to the IPv4LL address waits one > minute and then broadcasts for and acquires a new lease from the dhcp server. > The problem persists until dhcpcd is restarted. This should be fixed in dhcpcd-4.0.15 which was released a few days ago.
(In reply to comment #17) > (In reply to comment #14) > > I have hit this bug too. The problem is described here: > > http://roy.marples.name/projects/dhcpcd/ticket/161 > > > > I believe it is fixed in newer versions of dhcpcd. I'm using 4.0.13. > > > > The problem starts after loss of carrier. dhcpcd switches to a IPv4LL address. > > Now all subsequent attempts to renew a lease fails with "send_packet: Invalid > > argument". Each time dhcpcd switches back to the IPv4LL address waits one > > minute and then broadcasts for and acquires a new lease from the dhcp server. > > The problem persists until dhcpcd is restarted. > > This should be fixed in dhcpcd-4.0.15 which was released a few days ago. > in tree now, thx
