in Mac OS X.
The Mac OS X DHCP client sometimes send a DHCPDISCOVER message while in the DHCP BOUND state; it should do so only while in the DHCP INIT state. This behavior is not in compliance with RFC 2231 ("Dynamic Host Configuration Protocol").
Receipt of a DHCPDISCOVER from a client results in our DHCP server terminating the client's old DHCP lease, as a client may only send a DHCPDISCOVER when it is in the DHCP INIT state. However, the Mac OS X DHCP client sometimes ignores the new DHCPOFFER messages sent to it, and instead continues to use the IP address it has just abandoned by sending the DHCPDISCOVER. That is, it remains in (or returns to) the BOUND state for the old (abandoned) lease.(If when the client sends the DHCPDISCOVER it really trying to perform "Detection of Network Attachment in IPv4 (DNAv4)", then what the clientis doing is also not in compliance with RFC 4436. As per that RFC, a device with an "operable address" should start in the DHCP INIT-REBOOT state and send a DHCPREQUEST.)
In this situation, when the Mac OS X DHCP client decides that the lease it imagines still belongs to it is due for DHCP RENEWAL, sometimes the DHCPREQUEST messages it sends are also malformed. Specifically, the DHCP 'Server IP Address Option' is 0, the DHCP 'Requested IP Address Option' is 0, and the 'ciaddr' field is 0. (There is no case where a DHCP client should send a DHCPREQUEST packet with that set of characteristics.) This is not in compliance with RFC 2231.
We have seen these problems in all versions of Mac OS X versions 10.4.2 through 10.5.0. (It's possible it was introduced earlier than 10.4.2, in version 10.4 or 10.4.1, and we only became aware of it starting in 10.4.2.) We have also seen it in 10.5.2 - 10.5.6 (although the DHCPREQUESTS are no longer malformed).
The result of the client's behavior is that sometimes Macs "steal" IP addresses no longer assigned for their use, interfering with service to other customers.
We refer to this as the "Mac OS X DHCP client sometimes remains BOUND after sending DHCPDISCOVER" bug.
We reported the problem to Apple; Apple looked into the matter, and responded that they believe that the Mac OX X DHCP client behaves correctly.
We sought opinions regarding this matter via the IETF DHCP Working Group mailing list. While there was some disagreement, the outcome of the discussion was that the DHCP client was not behaving in compliance with RFC 2231 and (if it is implementing DNAv4) RFC 4436.
We advised Apple of the outcome of that discussion. Apple indicated that they would again looking into the matter. Apple advised us that they believe the problem was corrected in version 10.5.1.
We have confirmed that versions 10.5.1 and later no longer send the malformed DHCPREQUEST packets described above. However, they continued to exhibit the rest of the problem.
We suspect that they are actually exhibiting a degenerate case of the "Mac OS X 10.5.x/iPhone OS 2.x running multiple simultaneous DHCP clients on a single network interface" described below.
It appears Apple addressed that issue starting in iPhone OS 3.0 and Mac OS X 10.6. And Apple has advised us that they believe the problem was addressed by the time Mac OS X version 10.6.3 was released.
The problem remains in Mac OS X 10.5.x.
The Mac OS X 10.5.x DHCP client sometimes behaves as if it is running multiple simultaneous DHCPv4 client instances on a single network interface. (That is, all the apparent instances are using the same DHCP Client Identifier.)
More details about this issue appears in Running Multiple Simultaneous DHCP Clients on a Single Network Interface Can Interfere With Service.
While not relevant to this document (which focuses on Mac OS X 10.5.x), we have also seen iPhones and iPods exhibit the same problem.
We refer to this as the "Mac OS X 10.5.x/iPhone OS 2.x running multiple simultaneous DHCP clients on a single network interface" bug.
We reported the issue to Apple in March 2009. We are not able to publish information about Apple's response to our report as Apple's response is protected by a "non-disclosure" clause.
However, without violating that non-disclosure clause, we can say that if one compares the source code Apple has published for the Mac OS X 10.5.8 and Mac OS X 10.6 clients, one of the changes is that in the newer code, the OS attempts to retain only a single IP address IP network at a time. (More accurately, if two leases have the same router IP and hardware address, Mac OS X 10.6 OS only retains one of the leases.) That change suggests that the problem may be resolved starting in Mac OS X 10.6. That would also imply it may be addressed starting in iPhone OS 3.0.
Beginning in May 2009, we started seeing a small number of cases where a Mac OS X 10.5.6 client resumes using an IP address that it had acquired via DHCP, well after that DHCP lease has expired.
The client continues to use DHCP to obtain lease(s) on other addresses which it uses, but it simultaneously uses the IP address from the expired lease as well. The Mac is not hung, and the problem continues across disconnects and reconnects, sleeps and wakes, at least until the device is rebooted.
We refer to this as the "Mac OS X 10.5.6 resumes using an IP address from an expired DHCP lease" bug.
For two instances where we were fortunate to have detailed logs available from the client, the client's logs mentions that the client's configd process was experiencing a "too many open files" issue.
We reported the issue to Apple in May 2009.
The Mac OS X 10.5 firewall feature has an optional setting called "Stealth Mode". By default, the "Stealth Mode" feature is disabled. Enabling "Stealth Mode" causes the Mac to stop responding to ICMP requests. This means, for example, that the Mac will no longer respond to PING requests.
You should leave the firewall's "Stealth Mode" feature disabled.
If your Mac were to not respond to PING requests, it would sometimes be harder to perform some troubleshooting when your Mac experiences a network problem.
Additionally if your device ever uses a dynamically-assigned IP address (for example, an OIT Mobile IP Address) that is not assigned for its use at the time, and your Mac were not responding to PING requests, it would increase the likelihook that the IP address your Mac is "stealing" will be assigned (by OIT DHCP Service) to another device at the same time, resulting an a number of problems.
For these reasons, you should leave the firewall's "Stealth Mode" feature disabled.
We see a small number (several each month) in which a Mac OS X 10.5.8 client continues using an IP address that it had acquired via DHCP, after the client has sent an explicit DHCPRELEASE.
The client continues to use DHCP to obtain lease(s) on other addresses (which it uses), but it simultaneously uses the IP address from the released lease at the same time. This continues regardless of whether the original expiration time of the released lease has passed.
The Mac is not hung, and the problem continues across disconnects and reconnects, sleeps and wakes, at least until the device is reconfigured to clear the network preferences.
Over time (e.g. days), the problem worsens. That is, eventually the Mac decides to explicitly release its (new) legitimate DHCP lease. From that point on, it continues to use two IP addresses from released leases, plus whatever new IP address it obtains via DHCP in the future. This continues to worsen (the number of stolen IP addresses grows) until positive action is taken to fix the device.
We refer to this as the "Mac OS X 10.5.x continues to use an IP address after sending a DHCPRELEASE" bug.
We are unsure as to whether this is related to the "Mac OS X 10.5.6 resumes using an IP address from an expired DHCP lease" bug described above.
We reported the issue to Apple in April 2010.
. (En dan nog het lef hebben om Microsoft te beschuldigen geen standaarden te respecteren
Hoe is die spreuk over
Gast
