You are not logged in.
Whenever I try to setup my network with /etc/rc.d/network I always fail to get a lease. When I execute the same command manually, I get an IP and everything associated with it.
I've added the lines below to the network script for debugging:
echo 'whoami: '`whoami`
echo 'which dhcpcd: '`which dhcpcd`
echo '$DHCPCD_ARGS: '$DHCPCD_ARGS
echo '$interface: '$interfaceI've set it to debug mode, and have the output when running it below
[foo@bar etc]$ sudo rc.d/network start
:: Starting network [BUSY]
whoami: root
which dhcpcd: /usr/sbin/dhcpcd
$DHCPCD_ARGS: -d
$interface: eth0
dhcpcd[3483]: version 5.5.6 starting
dhcpcd[3483]: eth0: using hwaddr 52:44:a3:6c:c2:72
dhcpcd[3483]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[3483]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason NOCARRIER
dhcpcd[3483]: eth0: carrier acquired
dhcpcd[3483]: eth0: using hwaddr 52:44:a3:6c:c2:72
dhcpcd[3483]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd[3483]: eth0: carrier lost
dhcpcd[3483]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason NOCARRIER
dhcpcd[3483]: eth0: waiting for carrier
dhcpcd[3483]: eth0: carrier acquired
dhcpcd[3483]: eth0: using hwaddr 52:44:a3:6c:c2:72
dhcpcd[3483]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd[3483]: eth0: broadcasting for a lease
dhcpcd[3483]: eth0: sending DISCOVER (xid 0xc83b6419), next in 4.84 seconds
dhcpcd[3483]: eth0: sending DISCOVER (xid 0xc83b6419), next in 8.24 seconds
dhcpcd[3483]: eth0: sending DISCOVER (xid 0xc83b6419), next in 16.37 seconds
dhcpcd[3483]: timed outYet I run the same command manually and everything's happy:
[spitfire@killdesk etc]$ sudo /usr/sbin/dhcpcd -d eth0
dhcpcd[3511]: version 5.5.6 starting
dhcpcd[3511]: eth0: using hwaddr 52:44:a3:6c:c2:72
dhcpcd[3511]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[3511]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd[3511]: eth0: broadcasting for a lease
dhcpcd[3511]: eth0: sending DISCOVER (xid 0xfddd3649), next in 4.66 seconds
dhcpcd[3511]: eth0: offered 192.168.1.1 from 192.168.1.254
dhcpcd[3511]: eth0: sending REQUEST (xid 0xfddd3649), next in 3.31 seconds
dhcpcd[3511]: eth0: acknowledged 192.168.1.1 from 192.168.1.254
dhcpcd[3511]: eth0: checking for 192.168.1.254
dhcpcd[3511]: eth0: sending ARP probe (1 of 3), next in 1.94 seconds
dhcpcd[3511]: eth0: sending ARP probe (2 of 3), next in 1.40 seconds
dhcpcd[3511]: eth0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd[3511]: eth0: leased 192.168.1.1 for infinity
dhcpcd[3511]: eth0: adding IP address 192.168.1.1/24
dhcpcd[3511]: eth0: adding route to 192.168.216.0/24
dhcpcd[3511]: eth0: adding default route via 192.168.1.254
dhcpcd[3511]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd[3511]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd[3511]: forking to background
dhcpcd[3511]: forked to background, child pid 3537What am I doing wrong, and/or what can I do to fix this?
Offline
oh yeah, some system info:
Linux bar 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux
dhcpcd 5.5.6
Copyright (c) 2006-2012 Roy MarplesOffline
You can try moving network more to the right in the rc.conf daemon array,
Offline
the network script I ran above was run from the command line via: sudo /etc/rc.d/network start
after the system started up and I logged in. Basically the /etc/rc.d/network startup script is broken for me. For some reason dhcpcd when run from the script fails, yet when I run it manually it is successful.
Offline
Yes, I understand that from your previous post also. Moving network right means it is started later.
Show your daemon array from rc.conf.
Offline
I have exactly the same problem like ssptfire. It's almost 5 months now. Moving network to a later position in rc.conf didn't do the trick. I put dhcpcd to rc.local as a workaround. But there must be a better solution.
Offline
Ok, yes. Sorry for insisting. I actually did overlook that ssptfire is showing the fail by restarting the network script from the commandline. In that case it does not matter anyway which position I assume.
The only option I have added here early on in dhcpcd.conf is "noip4all". I wonder what happens if you put that in, as well as the "noarp" and "waitip" options. Maybe that makes a difference. (The last two I gathered from the dhcpcd 5.6 in testing).
Offline
Maybe I got something wrong here but didn't sspitfire write that dhcpcd only works when starting it manually after it failed at startup? What exactly is "noip4all" supposed to do, I'm asking because it didn't work for me. I tried "noip4ll" like written in dhcpcds manpage without any effort .
"noarp" and "waitip" also had no positive effect. Maybe I leave dhcpcd in the rc.local even if it's a bit of a dirty solution. ("noarp" and "waitip" I gathered from the dhcpcd manpage).
Offline
I mis-spelled the option, should be "noipv4ll". But it won't make a difference to you, because it just tells dhcpcd _not_ to fall back to a link local (e.g. 169.*) address, when no IP is received via the dhcp request. You find more information on it in the Avahi wiki.
Practically your work-around with rc.local I find feasible until you find the reason. If the box does not provide a network service/share/etc., it could even be later in your logon script.
Offline
I had run in to a similar issue on my Gentoo setup and was extremely frustrated. I was trying to "up" an interface created by openvpn and was trying to get a lease via dhcp and the "up" script would fail to get the lease when called by openvpn but worked perfectly when I ran it manually.
This finally worked for me:
dhcpcd -b <rest of the options>
The -b forces dhcpd to background immediately. Honestly, I don't know how it helps but it did. Not sure if it works in your situation but give it a shot!
Offline