Problems with Mac OS X Clients

[Adrian Merwood]

David W. Hankins wrote:
> On Sat, May 06, 2006 at 08:24:00PM +0100, Adrian Merwood wrote:
>   
>> I am running 2 different (alternating) DHCP 3.0.3 servers - 1 on 
>> Mandrake 2006 and 1 on CentOS.  They both exhibit the same behaviour.  
>>     
>
> Did you build from source or package?
>
> It's hard to tell if you're using LPF or BSD sockets for transmission
> to these clients.
>
> An easy way to find out is to examine the startup blurbs ("Listening
> on ...").
>
> I ask because I know some distributions have, in the past, intentionally
> built using BSD sockets so that the dhcpd binary does not bypass firewall
> rules.
>
> I'm actually not sure what an OSX client will do if you use BSD sockets
> to transmit to them (and get broadcast ip-address or ethernet mac wrong).
> I've never tried it.  Windows sure doesn't like it though.  It's the FAQ
> place to start looking: is your DHCP server producing all-ones broadcasts
> meaning both IP address (255.255.255.255) and mac address.
>
>   
>> May  6 20:15:32 gateway dhcpd: DHCPDISCOVER from 00:16:cb:07:49:93 via eth1
>> May  6 20:15:32 gateway dhcpd: DHCPOFFER on 192.168.1.195 to 
>> 00:16:cb:07:49:93 via eth1
>>     
>
> Presuming the OFFER gets to the client (questionable but easy to
> verify if you own the client), and presuming the REQUEST, if any, would
> be able to reach the DHCP server (highly probable considering the
> DISCOVER does), then the only remaining explanation is that the client
> doesn't like something in (or not in) the offer for some reason.
>
> This is an Apple question, not an ISC one...we can only speculate as to
> what it finds lacking in the offer.
>
>   
>> The 192.168.1.64 address is from another network served by a built in 
>> DHCP server on an ADSL router which happily serves up addresses to OS X.
>>     
>
> We have a few OSX boxes here at ISC, and have had no issues.  I suspect
> the difference is that we don't utilize RFC1918 addresses.
>
> So this is possibly OSX brain damage stemming from the belief that the
> client has not changed networks (it's still on the same subnet).
>
> See also:
>
> 	http://www.ietf.org/rfc/rfc4436.txt
>
> Which I don't know if the OSX client implements or not, but it does
> have an Apple employee on the authors list.
>
>
> If all else fails, compare ethereal traces of the two networks from
> the client's point of view.  See what's different.  Don't filter the
> trace down to just DHCP - you want to see ARP and maybe ICMP too.
>
> If you don't mind emailing them to dhcp-bugs at isc.org, I get a kick
> out of looking at DHCP packets over lunch sometimes.
>
>   
Thanks for your reply, I am away travelling at the moment so cannot get 
traces.  I have looked at the startup and see the following:

Listening on LPF/eth1/00:15:f2:98:46:d2/192.168.1/24
Sending on   LPF/eth1/00:15:f2:98:46:d2/192.168.1/24
Sending on   Socket/fallback/fallback-net

I have the same problem if I renew the mac once it has an auto assigned 
address so I don't think the other network is part of the problem.  This 
was definately working fine at one point.  I am considering regressing 
to an older version of DHCP and see if the problem still exits.

As I said I will try to get some traces of the network whilst the mac is 
renewing its address from both the router and the linux box and will 
send them over.  I want to figure out if this is a problem that I need 
to report to apple and what to tell them when I do.

Thanks again for your help

Adrian