> I am running SCO Unix r3.2v4.2 and last night I downloaded the dhcpd
> sources from ISC (DHCPD-BETA-5.14).
> After a little tweaking of source code and the make file I got it to
> compile, seemingly.
> It is working very well to answer bootp requests from our DOS based PCs
> running PC/TCP 2.31 and also answers bootp requests from our Macintosh
> clients. My feeling is that it's answering these requests even faster
> than the bootp requests from SCO's bootpd.
> What ISN'T working is DHCP requests from a Windows 95 client (possibly
> Macintosh clients as well). When I boot up a Windows 95 client that is
> configured to gain it's IP address automatically using DHCP I get the
> following messages on the SCO system from the DHCP server:
> DHCPDISCOVER from 0:0:c0:21:e1:80 via wdn0
> DHCPOFFER on 184.108.40.206 to 0:0:c0:21:e1:80 via wdn0
> and then immediately on the Windows 95 client I get an error window which
> says "This DHCP client was unable to obtain an IP network address from a
> DHCP server. Do you want to see future DHCP messages?"
> 220.127.116.11 is the first in a range of addresses I set up in the
> dhcpd.conf file for dynamic assignment.
> Has anyone gone through setting up this server already?
> My suspicion is either the dhcpd daemon is broadcasting the reply to the
> wrong address and the Windows 95 client isn't receiving it OR that I've
> got something mis-configured in the dhcpd.conf file which a DHCP client is
> What I'm hoping is that someone else has this software running on a SCO
> box and is willing to share their configuration file and/or insights based
> on the above.
documentation. Windows 95 insists that the DHCPOFFER response be sent
to the all-1s IP broadcast address, 255.255.255.255. The TCP/IP stack
in your SCO Unix 3.2v4.2 system refuses to send to that address;
attempts to send to all-1s are translated to the broadcast address of
the interface to which the packet is being sent: in your case, perhaps
the Unix server is on 18.104.22.168 and the network is not subnetted, so
the DHCPOFFER packet is being sent to that network's broadcast address,
I have seen a workaround for this under OpenServer Release 5. It
involves adding an IP interface whose real, legitimate broadcast is the
all-1s address. This was done by making an IP alias for the existing
interface, with a goofy netmask, something like:
ifconfig alias net0 10.1.1.1 netmask 10.0.0.0
Since TCP/IP 1.2.1 (the version for Unix 3.2v4.2) does not support IP
aliases, I don't think you can even use this workaround. I have seen
kludges to weakly support IP aliases by adding extra non-connected PPP
interfaces or extra loopback interfaces, but they are reputed to be
unstable. Plus, I still have never seen an adequate description of how
to implement either of those kludges.
So, in sum, you can get this to work under OpenServer Release 5 with a
medium amount of effort. Under older releases, there are too many
things going against you; I doubt you will get it to work.