iMac refuses to accept IP

[Tina Siegenthaler]

Von meinem iPad gesendet

Am 27.06.2012 um 19:49 schrieb Peter Rathlev <peter at rathlev.dk>:

> On Wed, 2012-06-27 at 13:55 +0200, Siegenthaler Tina wrote:
> ...
>> New iMac (not accepting IP):
> ...
>>    Option: (t=61,l=33) Client identifier
>>        Option: (61) Client identifier
>>        Length: 33
>>        Value: 013C075472CBC20000000000000000000000000000000000...
> ...
>> 
>> "Older" iMacs (OK):
> ...
>>    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)
> 
> Can you capture the second discover from the new client and take a look
> at the Client Identifier? My guess is that the second packet contains a
> 7 byte CI (just like the older clients) consisting of 0x01 and the MAC
> address (013C075472CBC2). The value above seems to be those 7 bytes and
> then 26 bytes of zero, which is not the same.
> 
> Client Identifier is always the key from the server's perspective. If CI
> changes it's a new host. This is mandatory per RFC2131/RFC4361.
> 
> If that's the problem there is no DHCP compliant way of solving the
> problem other than changing what the client sends as CI.
> 
> -- 
> 

Hi Peter

Ah - yes. That sounds very plausible and I'll check that tomorrow morning first thing. It would explain why the DHCP server doesn't simply offer the same IP again on the second discover. I had been wondering as to why that was, because usually, the DHCP server will happily do so even if the old lease has not yet expired.
If that is really the case, it will be difficult to change it on the client side, since this behavior is probably sitting somewhere in the firmware. I wonder if a different boot manager woul help here? Hm. Maybe I'll give it a try with rEFIt.

Tina