*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I have been unable to locate any FAQ or mailing list archive after joining
this mailing list today. My apologies in advance if this information is
already known.
I was setting up dhcpd on a network today, and ran into problems with
MacOS clients. Specifically, the MacOS system would completely lock
up immediately after communicating with the DHCP server. Here's the
configurations involved:
DHCP Server System:
FreeBSD 3.1-RELEASE
dhcpd 2.0b1PL18
Single ethernet interface, using private subnet 192.168.1.0/24
Dialup interface, using 'ppp' and 'natd'.
Very simple setup in dhcpd.conf:
Assigns IPs from range 192.168.1.128 - 192.168.1.239
(currently a total of about 25 possible clients)
Options set for "routers" and "domain-name-servers" to
return 192.168.1.254
Dynamic BOOTP enabled
Lease times of one hour
Client Systems:
MacOS 8.0
TCP/IP 1.2, Open Transport 1.2
Setup for getting information via DHCP
Selected option in TCP/IP control panel for loading TCP/IP
only when needed.
The sequence of events was as follows:
Reboot MacOS system.
Start an app which used TCP/IP (Eudora, Telnet, etc.)
This triggers the startup of TCP/IP, and hence DHCP requests.
The DHCP server logs a discover/offer/request/ack sequence
for this system.
An appropriate lease entry is written to dhcpd.lease. [In other
words, all DHCP negotiations look fine on the server side.]
The MacOS system is then completely locked up.
The process repeats if the client system is rebooted.
Other clients (Win95, and MacOS 7.5 using MacTCP with BOOTP) would
work properly. These other clients would result in the same sequence
of events as seen on the server side (of course, the bootp clients
would send bootp messages, not dhcp messages), but would be able to
go on working properly.
The MacOS systems which kept locking up with this new setup had been
previously working just fine with a completely different DHCP server
that had been on the network. That other server was a MacOS system
running the Vicomsoft Internet Gateway Software. The only change on
the network had been to replace the old MacOS-based server with this
FreeBSD-based server. It was a direct swap-out, with the new server
taking over the IP address of the old server. [There was definitely
no chance of conflict with the previous server, it was removed from
the network entirely.]
In the end, I was able to fix the problem on the faulty MacOS systems
by deselecting the option on the TCP/IP control panel that kept TCP/IP
deactivated until it was needed. Now these systems bring up TCP/IP
as they are booting up, and make the DHCP requests at that time. They
get all the necessary information just fine, and network applications
work great without locking up the system.
This sounds like a problem in the MacOS TCP/IP stack, and might be
some sort of race condition involving the application's initial request
of TCP/IP services and the setup of the DHCP information. I probably
wouldn't even have brought it up here, except for the fact that these
systems worked flawlessly with the other DHCP server. So there is some
difference between the two servers which results in the MacOS system
getting seriously confused when the dhcpd server is used. Therefore
I'm submitting this info on the chance that it might be useful/interesting
to those working on the software, or to others trying to setup DHCP in a
network environment which contains Macs.
--
Michael Bryan
[EMAIL PROTECTED]
------------------------------------------------------------------------------
To unsubscribe from this list, please visit http://www.fugue.com/dhcp/lists
If you are without web access, or if you are having trouble with the web page,
please send mail to [EMAIL PROTECTED] Please try to use the web
page first - it will take a long time for your request to be processed by hand.
------------------------------------------------------------------------------
