Linux – ifconfig not reporting DHCP-assigned address

dhcpifconfiglinux

I'm updating the kernel for an appliance, and I've run into a change in how DHCP works. Near the end of my boot script, I check to see if I already have a DHCP-assigned address, and if not, I self-assign:

ifconfig eth0 169.254.1.1 up

Then, when DHCP finally gets me an address, it assigns it to eth0. And, in fact, this does seem to happen: if I can figure out the address of the appliance, I can talk to it on that DHCP-assigned address.

However, ifconfig continues to show the 169.254.1.1 address.

This is a new behavior I'm seeing with dhcpcd 5.2.12 and linux 3.2.9.

How can I self-assign an address for the case where there is no DHCP server, let DHCP override that assignment when it shows up, and subsequently, how can I find out my DHCP-assigned address?

root@appliance:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:22:4D:4F:B3:69  
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::222:4dff:fe4f:b369/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2686 errors:0 dropped:1 overruns:0 frame:0
          TX packets:589 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:403995 (394.5 Kb)  TX bytes:73691 (71.9 Kb)
          Interrupt:20 Memory:fa200000-fa220000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:985 (985.0 b)  TX bytes:985 (985.0 b)

root@appliance:~# grep dhcp /var/log/messages
Jul 18 16:03:55 (none) dhcpcd[2330]: version 5.2.12 starting
Jul 18 16:03:56 (none) dhcpcd[2330]: eth0: waiting for carrier
Jul 18 16:03:57 (none) dhcpcd[2330]: eth0: carrier acquired
Jul 18 16:03:57 (none) dhcpcd[2330]: eth0: broadcasting for a lease
Jul 18 16:03:57 (none) dhcpcd[2330]: eth0: offered 10.10.0.177 from 10.10.0.1
Jul 18 16:03:57 (none) dhcpcd[2330]: eth0: acknowledged 10.10.0.177 from 10.10.0.1
Jul 18 16:03:57 (none) dhcpcd[2330]: eth0: checking for 10.10.0.177
Jul 18 16:04:02 (none) dhcpcd[2330]: eth0: leased 10.10.0.177 for 86400 seconds
Jul 18 16:04:02 (none) dhcpcd[2330]: forked to background, child pid 2868

Best Answer

The whole idea of RFC3927 is that the address should be stateless. As such, DHCP clients are supposed to randomly generate the last two octets of the address and subsequently verify that said address is unique via an ARP. Statically setting a value (i.e. 169.254.1.1) defeats that purpose. Let dhcpcd (or whichever client you're using) do its job and it may address your issue.

Related Topic