User Guide
Contents
DHCP and Mac OS
- Introduction to Macintosh DHCP
- Switching Open Transport Libraries
- 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.
<http://til.info.apple.com/techinfo.nsf/artnum/n58372>
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:
<http://til.info.apple.com/techinfo.nsf/artnum/n25049>
(Apple's note on DHCP implementation in 9.0-9.0.2
Top
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:
OT2.6
Open Transport
Open Transport ASLM Modules
OpenTPT Remote Access
OpenTpt Modem
OpenTpt Serial Arbitrator
With these:
OT2.0.3
Open Tpt AppleTalk Library
Open Tpt Internet Library
Open Transport Library
OpenTpt Remote Access
OpenTptAppleTalkLib
OpenTptInternetLib
OpenTransportLib
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.
Top
Other Related References
Using IPNetRouter's DHCP Server
DHCP FAQ --
http://www.dhcp-handbook.com/dhcp_faq.html
For more information on DHCP, refer
to RFC-2131, RFC-2132, <http://www.dhcp.org/
>, or a good book on TCP/IP.
Top
|