dhcpcd fail after upgrade

Shaika-Dzari · 2007-07-31 02:14:31

Hello!

After upgraded to dhcpcd 3.1.1-1, my network is unreacheable.
I downgraded to 3.0.19-1 and everything worked again.

I'm not sure but dhcpcd seem to use a file ( I think this is /var/lib/dhcpcd/dhcpcd-eth0.info ) with bad ipadress, netmask, etc...

@+

festgreifaah · 2007-07-31 06:20:23

I encountered the same problems. After downgrading everything works.

Using netcfg to connect it reported a timeout.
Ifconfig showed some ipaddress which didn't fit with my networtk.

skymt · 2007-07-31 06:23:56

This may be related:

http://developer.berlios.de/bugs/?func= … up_id=4229

mykhal · 2007-07-31 15:24:59

same problem here. I was told that dhcpcd is sending incorrect MAC address, as seen in the dhcp server logs. However, "dhcpcd -d eth0" looks OK.

there's a bug report 7715

Last edited by mykhal (2007-07-31 15:50:12)

mykhal · 2007-07-31 22:13:53

In my case, the problem is in the presence of DUID in the DHCP request, the dhcp server (probably microsoft), which did not understand it.
Appending -I "" option to dhcpcd fixes it, however. Unfortunately, changing

DHCPCD_ARGS="-t 30 -h $HOSTNAME"

to

DHCPCD_ARGS="-I '' -t 30 -h $HOSTNAME"

in /etc/conf.d/dhcpcd does not make a change... maybe some quotes escaping problem ? I need help here.

Snowman · 2007-08-01 06:22:02

try:
DHCPCD_ARGS="-I \"\" -t 30 -h $HOSTNAME"

mykhal · 2007-08-01 09:39:34

mykhal wrote:

problem is in the presence of DUID in the DHCP request, the dhcp server (probably microsoft), which did not understand it.

Maybe the better explanation is, that the server assigned to my computer (which has how DUID in addition to MAC) the new identity, and also new IP address to it. Unfortunately, some networks (including ours) may be configured in way, that the new address does not work, because it is not boud to the MAC in the registration database.

Snowman wrote:

try:
DHCPCD_ARGS="-I \"\" -t 30 -h $HOSTNAME"

It is the second thing I have tried (the first was DHCPCD_ARGS='-I "" -t 30 -h $HOSTNAME').
Unfortunately, they do not work. Processes list (ps ax), shows, that the quotes are used explicitely, so the DUID='""', so I got another different IP adress. Starting dhcpcd with -I "" by hand from command line, the quotes are not shown, there's only a space. However running from command line with -I without argument also does not work. Also any other combination of apostrophes and quotation marks, whoich would work in regularh bash/sh/zsh scripts, did not work for me n\in the config file

stylopath · 2007-08-01 12:23:39

Yesterday i tried installing Arch on another Notebook, and after configuring and installing i rebooted it. after reboot i didn't get a dhcp-response from my router (and the other notebook with identical configuration works!). I first expected some mistakes in configuration, but even after reinstalling i had the same problems.
Network runs, until the first reboot after updating it's broken.

Is this problem related ? If yes, this might be very unhappy for those deciding to try Archlinux that have a dhcp-svr at home - First it seems to work, and after lots of work everything is gone.

I don't know how to downgrade (especially without internet-connection) and so i also can't gain access to the internet to update to a higher version (if it gets fixed soon) - Should i now wait until this is fixed and then reinstall again ? Or should i download a fixed package manually, burn it on disc and install it manually on the other machine ? Damn, i think i found the answer myself

Which versions are related to that problem? 3.1.1.1? 3.1.3.1 ?
My first notebook (the one that works ) runs 3.1.1.1 at the moment without problems and 3.1.3.1 is offered by pacman -Syu and 3.1.3.1 is the one that seems to make problems on my second notebook.

mykhal · 2007-08-01 12:49:06

stylopath, I don't think your problem is exactly the same as mine, because last dhcpcd arch package version, which worked for me, is 3.0.17. 3.1.1 is the problem one. But you can make sure killing your dhcpcd, and running it again with the -I option:

root@localhost# killall dhcpcd
root@localhost# dhcpcd -I "" -d

(-d option makes verbose output, you can find them some problem reports)

mrunion · 2007-08-01 14:25:43

I am having problems with dhcpcd as well, though different from yours. I'm not hijacking your thread, I'm just posting here to "footnote" that I should watch this thread as advised. For my problem, see: http://bbs.archlinux.org/viewtopic.php?id=35771

mykhal · 2007-08-01 16:15:28

well, did you try something mentioned above ?

mrunion · 2007-08-01 20:27:15

Oh, yup. Didn't work. I still get the log full of messages. I'll try 3.1.3-2 this evening. Thanks guys!

JaDa · 2007-08-02 00:20:18

Hu Guys

I have here a problem and opened a topic. I am not sure if this is releated to the "dhcpcd"? Maybe you have some ideas for me. Thank you

mrunion · 2007-08-02 01:14:52

Nope, for me 3.1.3-2 didn't fix the problem of eth0 (my wired but unconnected LAN port) trying to keep getting a DHCP lease. How can I disable eth0 and make it stop filling up the logs with

Aug  1 21:11:12 plunkerbunkey dhcpcd[4762]: eth0: broadcasting for a lease
Aug  1 21:11:42 plunkerbunkey dhcpcd[4762]: eth0: timed out
Aug  1 21:11:42 plunkerbunkey dhcpcd[4762]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'
Aug  1 21:11:42 plunkerbunkey dhcpcd[4762]: eth0: checking 169.254.9.95 is available on attached networks
Aug  1 21:11:43 plunkerbunkey dhcpcd[4762]: eth0: adding IP address 169.254.9.95/16

every 40 seconds or so? It does this over and over and over and over....

This didn't happen with 3.0.19, but has with every version since (3.1.1, 3.1.3-1, 3.1.3-2). If someone could just let me know how to make it ignore eth0 I'd be much appreciative.

Last edited by mrunion (2007-08-02 01:15:22)

mykhal · 2007-08-02 09:54:00

Well, the problems with the new dhcpcd seem to be serious. I thought the DUID disabling will prevent the problem, but now I have problems very similar with those mrunion reported.
Trying connect with dhcpcd 3.1.3-2 to the network, and after obtaining NAK message, it sends another request, and such way is flooding the network with this broadcast.. Rx bytes reaches megabytes in few moments.. here is she dhcpcd output, when -d option is appended:

Info, eth0: dhcpcd 3.1.3 starting
Info, eth0: hardware address = XX:XX:XX:XX:XX:XX
Info, eth0: broadcasting for a lease
Debug, eth0: sending DHCP_DISCOVER with xid 0x5def391b
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x5def391b
Info, eth0: offered AAA.AA.AAA.AAA from BBB.BB.BB.BBB
Debug, eth0: sending DHCP_REQUEST with xid 0x5def391b
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x5def391b
Info, eth0: received NAK: (null)
Info, eth0: broadcasting for a lease
Debug, eth0: sending DHCP_DISCOVER with xid 0x5deea418
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x5deea418
Info, eth0: offered AAA.AA.AAA.AAA from BBB.BB.BB.BBB
Debug, eth0: sending DHCP_REQUEST with xid 0x5deea418
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x5deea418
Info, eth0: received NAK: (null)
Info, eth0: broadcasting for a lease
Debug, eth0: sending DHCP_DISCOVER with xid 0x583ad81d
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x583ad81d
Info, eth0: offered AAA.AA.AAA.AAA from BBB.BB.BB.BBB
Debug, eth0: sending DHCP_REQUEST with xid 0x583ad81d
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: got a packet with xid 0x583ad81d
Info, eth0: received NAK: (null)
Info, eth0: broadcasting for a lease
...
...

(this "waiting 30 seconds" is a lie, the DHCP discovers are sent without a delay, flooding the network)

Luckily, I have another MAC address (and IP) registered in this room.network, I tried it and it works. The output is following:

Info, eth0: dhcpcd 3.1.3 starting
Info, eth0: hardware address = YY:YY:YY:YY:YY:YY
Info, eth0: broadcasting for a lease
Debug, eth0: sending DHCP_DISCOVER with xid 0x3f362799
Debug, eth0: waiting on select for 30 seconds
Debug, eth0: sending DHCP_DISCOVER with xid 0x3f362799
Debug, eth0: got a packet with xid 0x3f362799
Info, eth0: offered CCC.CC.CCC.CCC from BBB.BB.BB.BBB
Debug, eth0: sending DHCP_REQUEST with xid 0x3f362799
Debug, eth0: waiting on select for 27 seconds
Debug, eth0: got a packet with xid 0x3f362799
Info, eth0: checking CCC.CC.CCC.CCC is available on attached networks
Debug, eth0: sending ARP probe #1
Debug, eth0: sending ARP probe #2
Debug, eth0: sending ARP probe #3
Debug, eth0: sending ARP claim #1
Debug, eth0: sending ARP claim #2
Info, eth0: leased CCC.CC.CCC.CCC for 691200 seconds
Debug, eth0: renew in 345600 seconds
Debug, eth0: rebind in 604800 seconds
Info, eth0: adding IP address CCC.CC.CCC.CCC/24
Info, eth0: adding default route via CCC.CC.CCC.1 metric 0
Debug, eth0: writing /etc/resolv.conf
Debug, eth0: /etc/ntp.conf already configured, skipping
Debug, eth0: /etc/ntpd.conf already configured, skipping
Debug, eth0: writing /var/lib/dhcpcd/dhcpcd-eth0.info
Debug, eth0: forking to background

What is strange, that downgrading to the 3.0.17 version does not fix this problem, with the original MAC, now.. I has changed something irreversibly.

mrunion · 2007-08-02 13:05:23

That's unfortunate. Rolling back to 3.0.19 solved my issue. Is there any information you;d like from me on config files, etc? I can't do much because I don't know enough, but I'll do what I can.

mrunion · 2007-08-06 12:27:17

FWIW: I performed an upgrade yesterday and got the kernel2.6.22.1-4 (I had 2.6.22.1-3 before). When using the latest dhcpcd3.1.3-2 I no longer get the log filled with the messages about the disconnected eth0 (wired LAN) trying to obtain an IP lease. It seems that the problem may be fixed for me at least because of 3.1.3-2 acting OK under the 2.6.22.1-4 kernel.

kakabaratruskia · 2007-08-06 19:11:14

You must add the -A option to dhcpcd, so it won't perform the ARP test. It worked for me at least.

mrunion · 2007-08-08 12:42:13

I'm going to try the "-A" option because after a reboot the log started filling again. I'll see what it does! If that doesn't work I guess I'll just let the log fill up. It's only hard drive space!

mrunion · 2007-08-08 17:03:30

No dice on the "-A" option. The /var/log/everything.log still fills up with requests to get the unconnected eth0 an IP address. Maybe the problem is with ifplugd, I don't know. as the problem doesn't caus me any "problems", I'm just leaving it as is and letting the thing go.

JaDa · 2007-08-09 15:26:33

The problems was with the rolling release.
since July 24, 2007 after I have make an "pacman -Syu" update, I have trouble with my network. kernel26 2.6.22.1-3, is maybe the problem. but now it is kernel26 2.6.22.1-4 and the problem is still there.

Yesterday I have format my Testbox. I Installed ArchLinux "2007.08 Don't Panic" and the problem was gone. What is the problem, I don't know.

Last edited by JaDa (2007-08-09 15:28:33)

audaly · 2007-08-09 21:15:27

The "A" option solved the problem for me

JaDa · 2007-08-10 03:40:57

kakabaratruskia wrote:

You must add the -A option to dhcpcd, so it won't perform the ARP test. It worked for me at least.

audaly wrote:

The "A" option solved the problem for me

Description:
Since version 3.1.x of dhcpcd, some users (including myself) have been experimenting problems requesting an IP address from their ISP servers. I noticed the only difference between the old version, and the new one, is that the new one does an ARP check, which brings trouble to some users, while the old one didn't do that check. Anyway, the ARP check can be disabled with the -A option. I would suggest changing the default /etc/conf.d/dhcpcd to this:

DHCPCD_ARGS="[b]-A[/b] -t 30 -h $HOSTNAME"

this solved my problem,

thank's to all

Olnex · 2009-03-18 03:47:37

Sorry, do I need to add -A --- the square bracket of b and /b???
also, do I replace= $HOSTNAME with my actual host name or is it just a variable name that points to the actual host name?
Thanks !!!

Last edited by Olnex (2009-03-18 03:48:38)

ataraxia · 2009-03-18 12:20:24

Don't put square brackets. That's messed up forum markup.

I don't think you want to add the "-h $HOSTNAME" part if it's no already there anyway, just do the -A.

This thread is really old. We ought to close it since some of this info is likely out of date.

Arch Linux

#1 2007-07-31 02:14:31

dhcpcd fail after upgrade

#2 2007-07-31 06:20:23

Re: dhcpcd fail after upgrade

#3 2007-07-31 06:23:56

Re: dhcpcd fail after upgrade

#4 2007-07-31 15:24:59

Re: dhcpcd fail after upgrade

#5 2007-07-31 22:13:53

Re: dhcpcd fail after upgrade

#6 2007-08-01 06:22:02

Re: dhcpcd fail after upgrade

#7 2007-08-01 09:39:34

Re: dhcpcd fail after upgrade

#8 2007-08-01 12:23:39

Re: dhcpcd fail after upgrade

#9 2007-08-01 12:49:06

Re: dhcpcd fail after upgrade

#10 2007-08-01 14:25:43

Re: dhcpcd fail after upgrade

#11 2007-08-01 16:15:28

Re: dhcpcd fail after upgrade

#12 2007-08-01 20:27:15

Re: dhcpcd fail after upgrade

#13 2007-08-02 00:20:18

Re: dhcpcd fail after upgrade

#14 2007-08-02 01:14:52

Re: dhcpcd fail after upgrade

#15 2007-08-02 09:54:00

Re: dhcpcd fail after upgrade

#16 2007-08-02 13:05:23

Re: dhcpcd fail after upgrade

#17 2007-08-06 12:27:17

Re: dhcpcd fail after upgrade

#18 2007-08-06 19:11:14

Re: dhcpcd fail after upgrade

#19 2007-08-08 12:42:13

Re: dhcpcd fail after upgrade

#20 2007-08-08 17:03:30

Re: dhcpcd fail after upgrade

#21 2007-08-09 15:26:33

Re: dhcpcd fail after upgrade

#22 2007-08-09 21:15:27

Re: dhcpcd fail after upgrade

#23 2007-08-10 03:40:57

Re: dhcpcd fail after upgrade

#24 2009-03-18 03:47:37

Re: dhcpcd fail after upgrade

#25 2009-03-18 12:20:24

Re: dhcpcd fail after upgrade

Board footer