iMac refuses to accept IP

Siegenthaler Tina tina at ieu.uzh.ch
Wed Jun 27 11:55:42 UTC 2012 

Dear list

I'm having a problem with iMacs of the newest generation (with a new/different network chip?) not accepting the IP address offered by my DHCP server (running dhcpd v4.1.0p1 in failover mode). All other computers (Mac, PC, Linux) can get IPs without any problems.

What happens:

- Client iMac starts up and issues a DISCOVER
- Server OFFERs IP
- Client REQUESTs IP
- Server ACKs
- 30 seconds later, the client issues a DISCOVER again. Server (this time the other peer) offers a different IP, which the client will then accept:

Jun 26 08:41:17 ieu-dhcp1 dhcpd[38564]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.20.129
Jun 26 08:41:18 ieu-dhcp1 dhcpd[38564]: DHCPOFFER on 130.60.20.226 to 3c:07:54:72:cb:c2 via 130.60.20.129
Jun 26 08:41:18 ieu-dhcp1 dhcpd[38564]: DHCPREQUEST for 130.60.20.226 (130.60.17.131) from 3c:07:54:72:cb:c2 via 130.60.20.129
Jun 26 08:41:18 ieu-dhcp1 dhcpd[38564]: DHCPACK on 130.60.20.226 to 3c:07:54:72:cb:c2 via 130.60.20.129
Jun 26 08:41:55 ieu-dhcp1 dhcpd[38564]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.20.129: load balance to peer DHCP-IEU
Jun 26 08:41:57 ieu-dhcp1 dhcpd[38564]: DHCPREQUEST for 130.60.20.216 (130.60.33.131) from 3c:07:54:72:cb:c2 via 130.60.20.129: lease owned by peer

Jun 26 08:41:17 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.20.129: load balance to peer DHCP-IEU
Jun 26 08:41:18 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPREQUEST for 130.60.20.226 (130.60.17.131) from 3c:07:54:72:cb:c2 via 130.60.20.129: lease owned by peer
Jun 26 08:41:55 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.20.129
Jun 26 08:41:56 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPOFFER on 130.60.20.216 to 3c:07:54:72:cb:c2 (ieu0629) via 130.60.20.129
Jun 26 08:41:57 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPREQUEST for 130.60.20.216 (130.60.33.131) from 3c:07:54:72:cb:c2 (ieu0629) via 130.60.20.129
Jun 26 08:41:57 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPACK on 130.60.20.216 to 3c:07:54:72:cb:c2 (ieu0629) via 130.60.20.129


For a "normal" client, the log looks like this:

Jun 27 11:30:07 ieu-dhcp1 dhcpd[38564]: DHCPDISCOVER from 00:16:cb:84:c8:f6 via 130.60.20.129
Jun 27 11:30:08 ieu-dhcp1 dhcpd[38564]: DHCPOFFER on 130.60.20.218 to 00:16:cb:84:c8:f6 via 130.60.20.129
Jun 27 11:30:09 ieu-dhcp1 dhcpd[38564]: DHCPREQUEST for 130.60.20.218 (130.60.17.131) from 00:16:cb:84:c8:f6 via 130.60.20.129
Jun 27 11:30:09 ieu-dhcp1 dhcpd[38564]: DHCPACK on 130.60.20.218 to 00:16:cb:84:c8:f6 via 130.60.20.129

Jun 27 11:30:07 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPDISCOVER from 00:16:cb:84:c8:f6 via 130.60.20.129: load balance to peer DHCP-IEU
Jun 27 11:30:09 130.60.33.131 ieu-dhcp2 dhcpd[15432]: DHCPREQUEST for 130.60.20.218 (130.60.17.131) from 00:16:cb:84:c8:f6 via 130.60.20.129: lease owned by peer


My main problem is that we assign "fixed" IPs not by the fixed-address statement but by creating a pool with a single IP for every computer that needs a fixed address, and the allow only that computer (via classes / subclasses) in that pool. Which means that in the case of the new iMacs, there is no second address that the server could offer when the client doesn't accept the first IP... thus the client will start issuing DISCOVERS in regular intervals and the servers will respond with "peer holds all free leases":

Jun 27 12:15:09 ieu-dhcp1 dhcpd[41335]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:10 ieu-dhcp1 dhcpd[41335]: DHCPOFFER on 130.60.48.179 to 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:10 ieu-dhcp1 dhcpd[41335]: DHCPREQUEST for 130.60.48.179 (130.60.33.131) from 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:10 ieu-dhcp1 dhcpd[41335]: DHCPACK on 130.60.48.179 to 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:47 ieu-dhcp1 dhcpd[41335]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129: peer holds all free leases
Jun 27 12:15:49 ieu-dhcp1 dhcpd[41335]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129: peer holds all free leases
Jun 27 12:15:51 ieu-dhcp1 dhcpd[41335]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129: peer holds all free leases

Jun 27 12:15:09 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:10 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPOFFER on 130.60.48.179 to 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:10 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPREQUEST for 130.60.48.179 (130.60.33.131) from 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:47 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129: peer holds all free leases
Jun 27 12:15:10 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPACK on 130.60.48.179 to 3c:07:54:72:cb:c2 via 130.60.48.129
Jun 27 12:15:49 130.60.33.131 ieu-dhcp2 dhcpd[17205]: DHCPDISCOVER from 3c:07:54:72:cb:c2 via 130.60.48.129: peer holds all free leases


Interestingly, this problem only seems to happen at startup and if the client's lease has expired. If I delete the (not-accepted) lease for that client's IP, upon the next DISCOVER, the client will again be offered that IP, and this time, it will accept it.
I checked the traffic between the client and the server on startup with tcpdump, and I noticed that the new iMacs seem to send a different parameter request list *on startup*:

New iMac (not accepting IP):

Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 1
    Transaction ID: 0x461ebf10
    Seconds elapsed: 0
    Bootp flags: 0x8000 (Broadcast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 130.60.48.129 (130.60.48.129)
    Client MAC address: 3c:07:54:72:cb:c2 (3c:07:54:72:cb:c2)
    Server host name not given
    Boot file name not given
    Magic cookie: (OK)
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
        Option: (53) DHCP Message Type
        Length: 1
        Value: 01
    Option: (t=55,l=7) Parameter Request List
        Option: (55) Parameter Request List
        Length: 7
        Value: 0103060F432B3C
        1 = Subnet Mask
        3 = Router
        6 = Domain Name Server
        15 = Domain Name
        67 = Bootfile name
        43 = Vendor-Specific Information
        60 = Vendor class identifier
    Option: (t=61,l=33) Client identifier
        Option: (61) Client identifier
        Length: 33
        Value: 013C075472CBC20000000000000000000000000000000000...
    Option: (t=57,l=2) Maximum DHCP Message Size = 1500
        Option: (57) Maximum DHCP Message Size
        Length: 2
        Value: 05DC
    End Option


"Older" iMacs (OK):

Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 1
    Transaction ID: 0x5de907ff
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 130.60.48.129 (130.60.48.129)
    Client MAC address: c8:2a:14:0f:0d:27 (c8:2a:14:0f:0d:27)
    Server host name not given
    Boot file name not given
    Magic cookie: (OK)
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
        Option: (53) DHCP Message Type
        Length: 1
        Value: 01
    Option: (t=55,l=10) Parameter Request List
        Option: (55) Parameter Request List
        Length: 10
        Value: 0103060F775FFC2C2E2F
        1 = Subnet Mask
        3 = Router
        6 = Domain Name Server
        15 = Domain Name
        119 = Domain Search
        95 = Lightweight Directory Access Protocol
        252 = Proxy autodiscovery
        44 = NetBIOS over TCP/IP Name Server
        46 = NetBIOS over TCP/IP Node Type
        47 = NetBIOS over TCP/IP Scope
    Option: (t=57,l=2) Maximum DHCP Message Size = 1500
        Option: (57) Maximum DHCP Message Size
        Length: 2
        Value: 05DC
    Option: (t=61,l=7) Client identifier
        Option: (61) Client identifier
        Length: 7
        Value: 01C82A140F0D27
        Hardware type: Ethernet
        Client MAC address: c8:2a:14:0f:0d:27 (c8:2a:14:0f:0d:27)
    Option: (t=51,l=4) IP Address Lease Time = 90 days
        Option: (51) IP Address Lease Time
        Length: 4
        Value: 0076A700
    Option: (t=12,l=13) Host Name = "ieu0596-TiMac"
        Option: (12) Host Name
        Length: 13
        Value: 696575303539362D54694D6163
    End Option
    Padding


Interestingly, the newer models send that different parameter request list **only at startup**. All subsequent DISCOVERs will contain the "normal" parameter request list (the same as the one of the older models, but then it's too late, maybe?)

Could that be part of the problem? I'm not sending any vendor specific options... my other hypothesis is that the new iMacs do request an IP too early on startup and then will "forget" it (they're issuing the first DISCOVER clearly earlier than older models).

If you need more information, please do no hesitate to ask (I didn't include my dhcp.conf since there's enough logs in this post already and I do not think that it will be helpful, but maybe I'm wrong).


Anyone has any ideas?


Thanks, Tina

More information about the dhcp-users mailing list