How to avoid Mac OS X temporarily setting its IP in the “link-local” range (169.254.x.x) at boot time

dhcplink-localmac-osxnetworking

I have a DNS and DHCP server (Linux machine) managing my LAN addresses and names.

Everything is configured and fully working once the clients are up and running, having every Mac OS X client a DHCP given IP in the private class 192.168.1.x as given by the DHCP server.

The problem rises on reboot, since each machine seems to start up in the 169.x.x.x range and only after having got the DHCP IP everything turns ok … this is temporary issue and takes only a few seconds. This is very annoying for me, because on the IDS the ARP watcher floods the logs with tons of 169.x.x.x "new" machines

Any idea to disable this behavior?

The supposed right behavior should be to get a local-link IP address if, and only if, the machine could not successfully gain a DHCP given IP.

Thanks in advance

EDIT:

I think there is no timing problem, as it seems that the DHCP server responses suddenly, being the macosx station to not continue the DHCP request sequence.

As shown by the following tcpdump output, we see that macosx falls back to link-local just after having asked (and having got reply) for a DHCP, it goes on with link-local and only after 8 seconds it retries and finishes a new DHCP request.

TCPDUMP OUTPUT:

    19:49:32.373567 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:32.373754 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300


    19:49:32.374119 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:32.774285 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:33.174403 arp who-has 169.254.22.58 tell 0.0.0.0
    19:49:33.574622 arp who-has 169.254.22.58 tell 169.254.22.58
    19:49:33.974890 arp who-has 169.254.22.58 tell 169.254.22.58
    19:49:33.984227 IP 169.254.22.58 > 224.0.0.251: igmp v2 report 224.0.0.251
    19:49:34.978606 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [5q] [4n] PTR (QM)? 58.22.254.169.in-addr.arpa.[|domain]
    19:49:35.078822 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 5/0/0 PTR[|domain]
    19:49:35.229123 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [4q] [4n][|domain]
    19:49:35.479441 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 [4q] [4n][|domain]
    19:49:35.728759 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 11/0/0[|domain]
    19:49:35.981123 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 58.22.254.169.in-addr.arpa. (44)
    19:49:36.081741 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 4/0/0 PTR[|domain]
    19:49:36.729630 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 11/0/0[|domain]
    19:49:36.808274 arp who-has fw1.dearchstudio.lan tell Conference-Rooms-Mac-mini.local
    19:49:36.808290 arp reply fw1.dearchstudio.lan is-at 00:0e:0c:69:b6:10 (oui Unknown)
    19:49:36.808424 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:36.808609 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300
    19:49:37.656051 IP 169.254.22.58 > 224.0.0.251: igmp v2 report 224.0.0.251
    19:49:38.081483 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 15/0/0[|domain]


    19:49:40.264083 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:4b:ac:ae:be (oui Unknown), length 300
    19:49:40.264252 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc: BOOTP/DHCP, Reply, length 300
    19:49:40.264735 arp who-has Conference-Rooms-Mac-mini.local tell 0.0.0.0
    19:49:40.664952 arp who-has Conference-Rooms-Mac-mini.local tell 0.0.0.0
    19:49:40.696059 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain]
    19:49:40.796526 IP 169.254.22.58.mdns > 224.0.0.251.mdns: 0*- [0q] 14/0/0[|domain]

dhcpd.log:

fw1:~# tail /var/log/dhcpd.log
Aug 11 19:45:52 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:45:56 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1
Aug 11 19:45:56 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:48:08 fw1 dhcpd: DHCPDISCOVER from 00:13:21:b8:46:e0 via eth1: network 192.168.1/24: no free leases
Aug 11 19:49:32 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:32 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:36 fw1 dhcpd: DHCPDISCOVER from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:36 fw1 dhcpd: DHCPOFFER on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:40 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 (192.168.1.254) from 00:25:4b:ac:ae:be via eth1
Aug 11 19:49:40 fw1 dhcpd: DHCPACK on 192.168.1.162 to 00:25:4b:ac:ae:be via eth1

I think STP is not a matter for this.

EDIT 2:

I definitively can assure that this behavior has nothing to do with any switch protocol or configuration, I connected a Mac mini with Snow Leopard Server directly to my arpwatcher interface and I saw the same behavior I had with the switch.

I think I can definitively say this is an Apple BUG in the link-local implementation in OS X.

Best Answer

It sounds like may have an issue with the DHCP request not being answered quickly enough. If configured for DHCP, the machine will startup with NO IP address (0.0.0.0) and send a broadcast requesting one. Only if it gets no reply in the required amount of time will it assign itself a local-link address.

Switches running spanning-tree will exhibit this behavior because they first have to go through the STP loop detection process before allowing the device to transmit. On Cisco switches you can turn on "spanning-tree portfast" to allow the device quicker access to the network.

Related Topic