Home / server / Questions / 50831
In Process
drAlberT
Asked: 2009-08-07 01:57:45 +0800 CST

How can I avoid Mac OS X temporarily setting its IP in the "link-local" range (169.254.x.x) at boot time?

  • 772

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.

networking mac-osx dhcp link-local

4 Answers

  1. Unfortunately I doubt you'll find a solution to this. Part of the reason is that Mac OS X, esp. 10.4 Tiger and later, is highly asynchronous. Most of the startup management has been handled by launchd since Tiger and I believe all of it is as of Leopard.

    launchd doesn't have any dependancy support, so most daemons and such have to do their own polling of services to see when they're up and ready or not (see System Startup Programming Topics: The Boot Process, but be aware that SystemStarter is gone as of Leopard). There are a number of frameworks that do the heavy lifting, such as System Configuration, but I'd assume that in order to make it all work they had to make the decision that if the ethernet port has a link but they haven't gotten a DHCP response yet that they need to set it to a local-link IP.

    • 2

  2. 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.

    • 2

  3. Since the link-local 169.254.0.0/16 block cannot be routed, why is it a concern for your IDS? Simply ignore it. (Just make sure that your routers really do block it.)

    In my opinion, every IPv4 host ought to get and keep an address in the 169.254.0.0/16 block, just as every IPv6 interface is already required to have a link-local address. They can be very useful when things break.

    • 2

  4. Rather than trying to modify the behaviour of the Macs (I doubt you can anyway) why not simply adjust the IDS rules or trigger levels? It seems to me that your IDS is overly sensitive to normal and expected network activity.

    • 1