iMac refuses to accept IP
Sten Carlsen
stenc at s-carlsen.dk
Wed Jun 27 12:34:23 UTC 2012
Siegenthaler Tina <tina at ieu.uzh.ch> wrote:
>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
>
>
Here there is first a discovery to both servers and an offer from ONLY server1, a request and an ack. A bit later there is another discover with an offer ONLY from server2. Appearently the MAC is not too happy with the first offer but it is willing to use it, then it tries again to see if some better offer comes along, now the next offer is accepted. Have you checked the two offers are identical? One could imagine that something is better in the second offer, else it would not make sense to switch IP.
This is btw contradicting your description later that it is a kind of "fixed" address, the two servers are offering different addresses. Another point is that only one of the servers is offering an address, my guess is that each time the host is turned on, it will switch between the addresses.
It may be looking for a boot file, to allow management of the host?
My guess is that this will be following the specific version of the OS, not the NIC. Do you have other hosts with the exact same version of OSX?
>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
>
>_______________________________________________
>dhcp-users mailing list
>dhcp-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/dhcp-users
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
More information about the dhcp-users
mailing list