2

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.

drAlberT
  • 10,949
  • 7
  • 39
  • 52
  • Similar behavior when my MBP wakes from sleep. My DHCP addresses are being served by a custom-built SmoothWall router, but this doesn't affect any of the Linux or Windows machines in my house. Clicking on the Airport icon seems to kickstart the WLAN discovery process, which seems to issue a new DHCP Request once my access point is rediscovered. As far as I'm concerned, if a device is going to choose to ignore the DHCP response, it really should attempt to fall back to its last-good address, rather than a random Link-Local address. Quite annoying, as the resume function is otherwise very quick. – Pickles Mar 30 '12 at 07:47
  • @Pickles, the problem with falling back to its "last-good" address is that the last address may now be in use by another device and then cause an IP conflict on the network, which is potentially far worse. – YLearn Apr 28 '15 at 13:29

4 Answers4

2

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.

morgant
  • 1,470
  • 6
  • 23
  • 33
  • So, you confirm in your latest words the idea of @Peter? In other words, even in the launchd environment you described the local-link sould be a drop down choice if the system had not a DHCP response?? I'll sniff the network to investigate this issue ... stay tuned :) – drAlberT Aug 06 '09 at 15:44
  • Basically, yeah. – morgant Aug 06 '09 at 16:52
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.

Peter
  • 5,453
  • 1
  • 26
  • 32
  • As said, the same behavior is observed with a cross cable. No switch problem. DHCP server responses suddenly, but OS X simply ignores it at first, it uses link-local, retries a DHCP request and __only now__ it brings it to end. – drAlberT Oct 14 '09 at 11:29
2

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.

Phil Karn
  • 31
  • 2
  • because everything not used/necessary should be switched off .. only things not enabled can't be hacked (hopefully) because shutting up logs is giving a potential attacker a potential Potter invisibility power .. because what should work in a way should not be circumvented, should be repaired IMHO of course – drAlberT May 28 '15 at 09:15
1

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.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
  • Eheh, I have already planned to implement such a "patch". What I am looking for is a solution, not just a workaround; the number of possible dirty solution is big, of course. NOTE: this is absolutely not a normal and expected behavior! This is a buggy implementation of an RFC (IMHO). A monitoring of ARP activity over a stable and well known LAN is a desirable feature I don't want to low down cause of an Apple mis-implementation. – drAlberT Sep 14 '09 at 07:37