Summary: | net-misc/dhcpcd-4.0.13 - failed to renew lease on x86_64 with e100 LAN card & 2.6.29-gentoo-r5 kernel | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | NiTr0 <nitr0> |
Component: | [OLD] Unspecified | Assignee: | Jeremy Olexa (darkside) (RETIRED) <darkside> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | base-system, dragos.ilie, georgelenzer, izio_fw, mendo, PSeiferth, quazgar, roy, welp |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
NiTr0
2009-07-08 19:49:37 UTC
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 |