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