Sustainable Sustworks - Tools for Internet Travel
Advanced Networking for Mactintosh Professionals


User Guide


DHCP and Mac OS

  1. Introduction to Macintosh DHCP
  2. Switching Open Transport Libraries
  3. Other DHCP References

Introduction to Macintosh DHCP

Apple has released several different versions of Open Transport, each of which behaves differently when resolving client negotations with a given DHCP server. Understanding the history of DHCP on MacOS can be important. DHCP is a subtle protocol that is still evolving.

If you have MacOS LAN clients in use on your network, we strongly recommend that you read Apple's TIL 58372. It describes some of the limitations between various versions of Open Transport up through 8.6.


Using the DHCP test tools in IPNetMonitor (2.3 or later) you can explicitely force a PowerMac to get a new DHCP lease and also test any DHCP server for other odd or unexpected behaviour. (See the IPNetMonitor area of our web site and IPNetMonitor's help info for more info on using these tools. You may well benefit from reading the RFC specifications for DHCP to understand what these tools do and what you should expect from a standards compliant DHCP server.)

Apple extended DHCP somewhat to accomodate wireless networks where a client might roam in and out of range of a DHCP server. If a client is unable to contact a DHCP server, it will try to auto-assign itself an IP address from the 169.254.x.x range, and then try again to contact the DHCP server every few minutes. Since a client can assign itself a temporary IP address, it may contact a DHCP server to request a new IP address while claiming to be bound to a different address. This creates a few possible conflicts:

  • The server may try to respond to the bound address (ciaddr) the client said it has. There is no guarantee the response will be routed to the correct network.
  • In Mac OS 8.6, the server may try to respond via hardware unicast. Since the client is already bound to a different IP address, it will not receive the response. The DHCP Server in IPNetRouter works around this by broadcasting the response if the first unicast response was not received.
  • In Mac OS 9, the client will always request a broadcast response to avoid these conflicts. The DHCP standard however is ambiguous on how to respond to a DHCP DISCOVER or REQUEST when 'ciaddr' is non-zero. Some DHCP servers may misinterpret the request.

Some other differences in the latest Macintosh DHCP clients:

  • When requesting or renewing an IP address, the Mac OS 9 client requests an explicit long lease time to insure any previous lease binding will be extended. Some DHCP servers do not respond properly to this request. They may reject it for example, instead of offering or granting a shorter lease time.
  • The time out values used for the DHCP client have been reduced to avoid long delays while trying to reach a DHCP server. If there is no response within a few seconds, the client will assume the server is currently unavailable.
  • Since the existing DHCP client runs synchronously, other processing comes to a halt while the DHCP client waits for a response. Reducing the time out interval helps eliminate the long pauses, but makes the Mac client more likely to regard a busy DHCP server as unavailable and therefore auto-assign itself an address (169.254.x.x) which is not functional on the attached network. This should be fixed Mac OS 9.0.4 (OT2.6.?).

Previous known issues:

  • Prior to Mac OS 8.6, the Mac DHCP client would release an assigned address when it was shutdown, and then try to request this address again upon restart. Some DHCP servers do not keep track of released lease bindings and would not respond causing excessive startup delays.
  • The Mac DHCP client would not request an explicit lease extension (address time) when attempting to renew a previous binding. Some DHCP servers that followed the RFC literally would use the remaining time on the previous lease binding so the lease was never actually renewed.

See also:

<> (Apple's note on DHCP implementation in 9.0-9.0.2


Switching Between OT 2.0.3 and 2.6 on MacOS 8.6 or 9.0

Many DHCP problems can be fixed by upgrading to the latest version of Open Transport.

Mac OS 9.0.4 updates Open Transport to version 2.6 which also works under Mac OS 8.6. You can upgrade Mac OS 8.6 to use OT2.6, or downgrade Mac OS 9.0.3 or later to use OT version 2.0.3 by exchanging these items in your Extensions folder:

Open Transport
Open Transport ASLM Modules
OpenTPT Remote Access
OpenTpt Modem
OpenTpt Serial Arbitrator

With these:

Open Tpt AppleTalk Library
Open Tpt Internet Library
Open Transport Library
OpenTpt Remote Access
OpenTpt Modem
OpenTpt Serial Arbitrator

Peter Sichel, the developer of IPNetRouter, keeps two folders on his hard drive named "Old OT" and "New OT". He then moves the libraries to and from the system Extensions folder and restarts the machine when he wishes to switch versions. This techique is also used at Apple when developing and testing Open Transport.

Apple does not support the switching of libraries in this fashion in released software. In general, the only way you can get particular libraries is by installing the version of the OS that a particular version of OT ships with. Be careful not to switch libraries when any networking applications are running. Because Apple typically tests and ships only one version of Open Transport with any particular OS, there may be other networking problems that arise by switching libraries. Also, some software packages may install or modify Apple's Open Transport libraries (even though they shouldn't). You may have to reinstall such software if you choose to switch OT libraries.


Other Related References

Using IPNetRouter's DHCP Server


For more information on DHCP, refer to RFC-2131, RFC-2132, < >, or a good book on TCP/IP.