
----------------------------------------------------------
NOV-DHC1.DOC -- 19980115 -- Email thread on NetWare & DHCP
----------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




There is a DHCP (Dynamic Host Configuration Protocol) FAQ by John Wobus,
jmwobus@syr.edu, at:

	http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html

------------------------------

Date: Thu, 13 Jun 1996 08:46:36 +0100
From: Eric Hall <ehall@NWC.COM>
Subject: Re: DHCPSRVR.NLM only works on local segment??

>IP. But, none of the machines can get a DHCP resolution unless I put them
>on the backone, which is the same segment as the DHCP server.
>
>Does Novell's TCPIP.NLM route DHCP requests over one server NIC to another
>server? Am I doing something wrong?

DHCP is an extension of BOOTP. Both DHCP and BOOTP are subnet-specific
address assignment protocols. They listen for broadcasts. In the IP world,
broadcasts are generally not sent across routers, as the Internet would be
crippled by X-terminals world-wide looking for a local font server.

In order for a remote BOOTP or DHCP server to see a broadcast on another LAN
segment, the router must forward the request to the server. This is done
with BOOTPFWD.NLM on the NetWare servers that act as routers, or with BOOTP
Forwarding on your cisco/bay routers.

------------------------------

Date: Thu, 13 Jun 1996 18:04:21 -0500
From: Don Wee <DWEE@WPO.IT.LUC.EDU>
Subject: Re: DHCPSRVR.NLM only works on local segment??

>DHCP is an extension of BOOTP. Both DHCP and BOOTP are subnet-specific
>address assignment protocols. They listen for broadcasts. In the IP world,
>broadcasts are generally not sent across routers, as the Internet would be
>crippled by X-terminals world-wide looking for a local font server.
>
>In order for a remote BOOTP or DHCP server to see a broadcast on another
>LAN segment, the router must forward the request to the server. This is
>done with BOOTPFWD.NLM on the NetWare servers that act as routers,
>or with BOOTP Forwarding on your cisco/bay routers.

Eric is perfectly correct and quite thorough in his explanation, but I'm
afraid Fred MIGHT be reporting a more serious  problem than just not
having any bootp forwarding agents active on his routing devices.

We, too have tried to set up DHCPSRVR.NLM on our backbone and
can only successfully use it on the backbone.  We DO have bootp
forwarding configured on our Ciscos and netware servers: we even tried
putting the DHCPSRVR into exactly the same port and same IP address as
our existing (and working) bootp server (LAN Workgroup).  Once we cleared
the ARP cache on the Cisco, we could see the DHCPSRVR report it was
getting the forwarded requests, but it would also complain that it could
not forward its reply back to the DHCP client.

(We have a call open with Novell, but they have been singularly unhelpful
on this one.) We ARE trying to use dhcpsrvr.nlm without using all features
of NW/IP, but it IS on a 4.1 server (even though we were tempted to try
what others had reported doing successfully, running DHCPSRVR.NLM on a
3.12 box.)

------------------------------

Date: Mon, 12 Aug 1996 08:13:11 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell DHCP -Reply

>>I downloaded the DHCP executable from the Novell WEB site. Is this
>>a standalone product or does it require Netware/IP???
>
>This product is stand alone.  It is a series of NLMs, one is DHCPSRVR.NLM
>and the other DHCPCFG.NLM, that runs very well.
--------
	No, it does not work "very well." It has serious problems, as
shown below in my message sent through another channel:

	Using DHCPSRVR.NLM v2.0 bundled with Green River/Beta I've noticed
three problems with it, one nasty.

	If a DHCP client releases its IP address then the server loses that
IP information even if the allocation is not from the dynamic IP pool. That
means a static table of MAC addresses vs IP addresses is lost if the client
returns an IP address which just happens to have an infinite lease time.
Static assignments do have infinite lease time. To recover one must load
DHCPCFG.NLM and reenter that client's information all over again. That's
nasty.
	If a DHCP client sends its requests (DISCOVER, REQUEST) to an IP
directed broadcast address (such as say 129.123.1.255) rather than to a
total IP broadcast address (255.255.255.255) then DHCPSRVR mistakenly
returns a server IP address (siaddr field in the Bootp/DHCP packet) as
that IP directed broadcast address rather than its own real IP address.
This is a nuisance and leads to extra network traffic from other servers.
	If file sys:etc\dhcptab is marked read-only, in an attempt to avoid
losing static assignments, then DHCPSRVR.NLM unloads itself. Such fragility.

	These gems were discovered as I was testing the new DHCP support
in MS-DOS Kermit v3.15/beta this Saturday.
	Joe D.

------------------------------

Date: Thu, 26 Sep 1996 23:45:27 -0400
From: Jason Lester <jlester@NAXS.COM>
Subject: DHCP Clients??

>If I wanted to run the DHCP Server nlm on my Netware 4.1 server, what
>would I need at the client end at the workstations (all are running
>Win 3.1)?
>
>Do I have to purchase a third party TCP/IP stack or does Novell
>provide any download-able software that can handle the job (as a DHCP
>client, that is)?

Sure, just download TCP16.EXE from the Novell ftp server.  It's in the
UnixConn directory I believe.  After running Install, it will ask if TCP
parameters are provided by a BOOTP server, answer yes.  That should take
care of it.  You could also use the new Dos/Windows Client32 which supports
the full DHCP spec instead of just BOOTP like the older drivers.

------------------------------

Date: Tue, 5 Nov 1996 08:20:32 -0600
From: "Mike Avery" <mavery@pernet.net>
To: netw4-l@bgu.edu
Subject: Re: [Client] VLM NET.CFG TCP/IP configuration

>I had set up my admin machine to use Client32 and the TCP/IP stack that
>is supplied with it.  It seemed to work great - used DHCP and everything!
>
>The problem has arisen because I want to install Intel LANDesk Manager 2.01
>and apparently, this is only supported on VLMs so I have to re-configure my
>workstation to use VLMs.  This is not too much
>
>However, I can't find any documentation on TCP/IP configuration.  I'd like
>to still use DHCP with the VLM client.  Is it supported?  Where can I find
>documentation on the relevant NET.CFG settings?

Quite frankly, I don't think that LANDesk is worth the trouble.  It
is an unstable product that patches the operating system in such a
way that it has to be rewritten every time a new version of NetWare
is released.  Once you start with LANDesk, you are forever on the
upgrade trail.  Some are free, some are charged for.  I am delighted
to no longer work for the shop that used LANDesk.

But that doesn't answer your question...  VLM's do quite well with
DHCP.  Here's my startnet.bat:

SET NWLANGUAGE=ENGLISH
cd\nwclient
lh LSL
lh 3c5x9
lh ipxodi

lh NET\BIN\TCPIP
lh VLM /ps=porky
:end_startnet
cd\

And here's my net.cfg:

SHOW DOTS = ON
CACHE BUFFERS = 0
FILE HANDLES = 45
ALL SERVERS = ON

Link Support
	Buffers	8 1514
	MemPool	4096

link driver smc8000
	Frame Ethernet_802.3
	Protocol IPX 0 ETHERNET_802.3
	frame ethernet_ii
	int 3
	port 280
	mem cc000

link driver 3c5x9
	Frame Ethernet_II
	Protocol IPX 0 ETHERNET_802.3
	Frame ETHERNET_802.3
	int 10
	PORT 300

Protocol TCPIP
	tcp_sockets 8
	udp_sockets 8
	raw_sockets 1
	PATH SCRIPT     C:\NET\SCRIPT
	PATH PROFILE    C:\NET\PROFILE
	PATH LWP_CFG    C:\NET\HSTACC
	PATH TCP_CFG    C:\NWCLIENT\NET\TCP

;otherwhen.com
	ip_router     0.0.0.0
	ip_netmask    0.0.0.0
	ip_address    0.0.0.0

NetWare DOS Requester
	FIRST NETWORK DRIVE = F
	NETWARE PROTOCOL = NDS BIND

And finally in the C:\NWCLIENT\NET\TCP directory, pointed to by the
PATH TCP_CFG line above, I have a file named resolv.cfg.  It points
to the name servers.  In my case it has the following contents:

domain  Otherwhen.COM
nameserver  205.229.2.17
nameserver  205.229.0.6

------------------------------

Date: Tue, 10 Dec 1996 09:17:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DOS/WIN Client32 + DHCP

>I am using DOS/WIN Client32 v2.11 and am successfully using the
>TCP/IP stack with DHCP to assign an host, gateway, and DNS
>addresses.
>
>The DHCP server is on a WindowsNT machine.
>
>The problem I am having is assigning a host name to the workstation.
>There is a TID which says to set a DOS variable (NAME) to the host
>name desired, but this does not seem to work. Neither the workstation
>nor the DHCP server see the value of this variable as the
>workstation's host name.
>
>Does anyone have any suggestions to enable assigning a host name to
>the workstation under these circumstances?
------------
	First, why bother? The local machine name is of use by other
stations, and has possible use as a field in email. It's not needed
to establish comms.
	Second, if Microsoft's DHCP server cannot offer a client name
then the logical next step is change DHCP servers. Try Novell's, for
example, which does work. Complaints and puzzles to MS on their product.
	Third, a DOS Environment variable is for programs prepared to
look for it, and that means applications level programs. TCP/IP stacks
normally don't do that sort of thing.
	Joe D.

------------------------------

Date: Tue, 21 Jan 1997 17:59:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP and LanWorkplace?

>I've found that BOOTP provides almost as much functionality as DHCP.
>BOOTP supposedly only sends an IP address to clients while DHCP provides
>DNS addresses, gateways, etc.  However, on our network BOOTP VLM clients
>get all this information too.  For DHCP access, upgrade to Client32 for
>DOS/Windows as it has a built-in DHCP client.
--------
	I'm afraid that's not correct. DHCP is nothing more or less than
BOOTP with United Nations style negotiations added to lease information.
The operational difference is bootp gives info and cannot know the client
is done with it (the client may shut down its TCP/IP stack but remember
settings elsewhere). DHCP negotiations imply either an infinite lease
(a static IP assignment, in essense, but at least both sides know this)
or a timed lease with the option for automatic renewal.
	The real client data is identical in both, so much so that when
I added DHCP support to MS-DOS Kermit this summer I used the bootp code
as the inner part, and negotiations were wrapped around it. I should say
that DHCP has several more "tags" to indentify negotiation material rather
than client IP scoop.
	While DHCP is more flexible about handing out addresses it is also
more bureaucratic and needs more code in the client to deal with the paper
work.
	At the risk of being yelled at, below is the decoder of packets
coming to the client, for both BOOTP and DCHP. Tags in the 50's are DHCP
negotiation material; the others are common to both methods. "p" is a
pointer marching down the packet contents.
	Joe D.

/* Decode Bootp/DHCP Options from received packet */
static void
decode(struct bootp * rbp)
{
	byte *p, *q;
	word len;

	p = &rbp->bp_vend[4];   /* Point just after magic cookie */
	q = p + 248 + 60;       /* q = end of all possible vendor data */

	while (*p != 255 && (q - p) > 0)
		switch(*p)
		{
		case 0: /* Nop Pad character */
			p++;
			break;
		case 1: /* Subnet Mask */
			sin_mask = ntohl(*(longword *)(&p[2]));
			p += *(p+1) + 2;
			break;
		case 3: /* gateways */
			for (len = 0; len < *(p+1); len += 4)
			  arp_add_gateway(NULL,ntohl(*(longword*)(&p[2+len])));
			p += *(p+1) + 2;
			break;
		case 6: /* Domain Name Servers (BIND) */
			for (len = 0; len < *(p+1); len += 4)
			add_server(&last_nameserver, MAX_NAMESERVERS,
			def_nameservers, ntohl(*(longword*)(&p[2 + len])));
			p += *(p+1) + 2;
			break;
		case 12: /* our hostname, hopefully complete */
			bcopyff(p+2, hostname, (int)(p[1] & 0xff));
			hostname[(int)(p[1] & 0xff)] = '\0';
			p += *(p+1) + 2;
			break;
		case 15: /* RFC-1395, Domain Name tag */
			bcopyff(p+2, kdomain, (int)(p[1] & 0xff));
			kdomain[(int)(p[1] & 0xff)] = '\0';
			p += *(p+1) + 2;
			break;

		case 51:        /* DHCP lease time, seconds */
			if (p[1] == 4)
				{
				DHCP_lease = ntohl(*(longword*)(&p[2]));
				if (DHCP_lease == -1L)  /* -1 is infinite */
					DHCP_lease = 0; /* no timeout */
				else
					DHCP_lease = set_timeout((int)(0xffff
						& DHCP_lease));
				}
			p += *(p+1) + 2;
			break;

		case 53:        /* DHCP commands from server */
			DHCP_state = p[2];      /* Command, to local state */
			p += *(p+1) + 2;
			break;
		case 54:        /* DHCP server IP address */
			if (p[1] == 4)
				DHCP_server_IP = ntohl(*(longword*)(&p[2]));
			p += *(p+1) + 2;
			break;
		case 58:        /* DHCP lease renewal time */
			if (p[1] == 4)  /* IP v4 is 4 bytes of address */
				{
				DHCP_renewal = ntohl(*(longword*)(&p[2]));
				if (DHCP_renewal == -1L)
					DHCP_renewal = 0;       /* no timeout */
				else
				     DHCP_renewal = set_timeout((int)(0xffff &
						DHCP_renewal));
				}
			p += *(p+1) + 2;
			break;
		case 59:        /* DHCP lease rebind time */
			if (p[1] == 4)
				DHCP_rebind = set_timeout((int)(0xffff &
					ntohl(*(long*)(&p[2]))));
			p += *(p+1) + 2;
			break;

		case 255:       /* end of options */
			break;
		default:
			p += *(p+1) + 2;
			break;
		  }                     /* end of switch */
}

------------------------------

Date: Tue, 4 Feb 1997 13:41:23 -0500
From: Robert MacDonald <RMACDONALD@PERRIGO.COM>
Subject: DHCP (& BOOTP) - long!

I have seen quite a few messages regarding DHCP & BOOTP. I hope I can shed
some light on this for those who are new to it. I'm not an expert on this
subject, so please be kind in any responses(or mistakes I inadvertantly
make :-))

I have been using Novells DHCP software for about a year on NW v4.10 with
BOOTP & DHCP clients using  on WIN31, WIN95, WINNT(3.5x & 4.) It's services
approximately 1300 users on 15 Token Ring and Ethernet segments. 4 of these
segments are accross a WAN. It's called DHCP2B.EXE and can be found at:

 ftp://ftp.novell.com/pub/updates/nwos/nw410/dhcp2b.exe.

It's included in Netware v4.11

You may want to reference RFC1533, 1534, 1541 and 1542. Please keep in mind
that each vendor has it's own little 'quirks' on how they handle extra DHCP
services, but generally they will do the basic DHCP 'stuff'.

DHCP is an extension or superset of BOOTP. This means, that you may use a
DHCP server to give out IP addresses to DHCP and BOOTP clients. BOOTP will
not be leased! It was designed for bootstrapping it's OS from a remote
server.

[_general_ info to follow...]

When a client wants an IP address, it will do a broadcast. If the DHCP
server is on the same segment, the server will see this request and send
back an IP address, subnet mask, domain name, etc.(really, there are 2/3
communications back and forth between the server and client.)

If the DHCP server is on a different segment, then you will need to forward
this request on to the proper segment(where the DHCP is.)

For BOOTP, you would set up BOOTP forwarding on _any_ netware server (does
not need to be a server with a presence in multiple segments. On NW v4.1,
use INETCFG to setup BOOTP foprwarding, on v3.x use BOOTPFWD) or enable
forwarding of this broadcast on the router servicing this segment (some
routers have this enabled by default.)

When the 'forwarder' sees this broadcast, it will attach to the broadcast,
the IP segment in which the broadcast came from(this is how the DHCP server
knows where to send the return message.) The DHCP server will know when a
client is using BOOTP and will not try to release or expire the address.
The DHCP server will keep the BOOTP clients in it's database, so whenever
the client re-requests for an IP, it will receive the same one. To make
these addresses available again, you will need to manually delete them (make
sure you reboot the BOOTP client if you do - or else it's duplicate time...)

[end of _general_ info...]

Some considerations. If you only have one DHCP server and you have multiple
segments, be sure to enable forwarding(except to the internet) of this
broadcast to the segment the DHCP server is on, so that the request will
reach the server. Also, be carefull on how you implement DHCP services.

Don't put multiple DHCP servers in a network(or same segment), leasing from
the same IP range. DHCP is broadcast driven, and you could end out the same
address to multiple clients.

With careful planning you can have multiple servers issuing(sp) addresses,
but it's tricky. One way, if you have small segments(<127 clients each),
would be to set up another DHCP server with the same hardcoded addresses as
the first, but it will only lease from a different range within that IP
class (Class C Ex: DHCP1 uses 1-127 and DHCP2 uses 128-254). Then if DHCP1
crashes, just power up DHCP2.

Make sure that you don't allow the server to give out addresses to those
hosts, that have hard coded addresses(specifically tell the DHCP server
about the host and the address assigned to it.) Most DHCP servers keep
track of these clients by storing their MAC address and NAME*, along with
the respective IP in a database on the server. The NAME comes from either
the username(for Netware) or the machine name(WIN95 & NT, etc.)

Some oddities I have noticed. Win95 will not give up a leased address when
it's supposed to(I have not looked to hard for an answer or patch either.)
This will lead to duplicate addresses and that's a pain in the 'keester'.

This is not an all inclusive document and some of it pertains specifically
to Novells version of DHCP, but most of it is general across platforms.
Pls read the RFC's and any documentation that comes with your DHCP server.

------------------------------

Date: Wed, 5 Feb 1997 10:49:10 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: DHCP (& BOOTP)

>Most DHCP servers keep track of these clients by storing
>their MAC address and NAME*, along with the respective IP
>in a database on the server. The NAME comes from either
>the username(for Netware) or the machine name(WIN95 & NT, etc.)

A curious thing about the NT DHCP server is that is uses the machine name
rather than the MAC address of the workstation to check for duplicate DHCP
requests/entries.

Naturally, if you're using the Client32 for DOS/Windows 3.1 then you don't
have a machine name set. To do this, put a set parameter in your
AUTOEXEC/STARTNET which does:

     set NAME=machinename
This is true for the NT 3.51 DHCP server. Microsoft may have change the
behaviour of their DHCP server in NT 4.0 - I haven't checked that yet.

---------

Date: Wed, 5 Feb 1997 17:58:06 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: DHCP (& BOOTP) - long!

>>Most DHCP servers keep track of these clients by storing
>>their MAC address and NAME*, along with the respective IP
>>in a database on the server. The NAME comes from either
>>the username(for Netware) or the machine name(WIN95 & NT, etc.)
>
>A curious thing about the NT DHCP server is that is uses the machine name
>rather than the MAC address of the workstation to check for duplicate DHCP
>requests/entries.
>
>Naturally, if you're using the Client32 for DOS/Windows 3.1 then you don't
>have a machine name set. To do this, put a set parameter in your
>AUTOEXEC/STARTNET which does:
>
>	set NAME=machinename
>This is true for the NT 3.51 DHCP server. Microsoft may have change the
>behaviour of their DHCP server in NT 4.0 - I haven't checked that yet.

BOOTP requests /must/ use the MAC address of the client

DHCP requests use the /client-id/ which must be unique on a subnet, and
can be any string...

------------------------------

Date: Thu, 6 Mar 1997 10:18:40 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell DHCP 2b and Win95

>we're having a problem getting DHCP 2b to work with Win95. In the
>DHCP config  each machine is configured with a workstation name.
>Win95 doesn't take over this workstation name. It does, however, add
>the Domain Search Suffix to the workstation name as it was already
>defined in the Win95 registry.
------------
	Best to be very careful about terminology here.
	Novell's DHCP server does work just fine, as it should. It does
not have a thing to do with NetBIOS stuff that Microsoft loves. The
"name" assigned to an IP address is an IP name, registered with your
local Domain Name Server; the client usually neither knows nor cares
about its IP name. The workstation is not the authorative source of IP
names and numbers; the DHCP server hands them out to the workstation(s).
	Solution: don't use Microsoft's networking. Or contact MS and
discuss their networking with them.
	Joe D.

------------------------------

Date: Tue, 29 Apr 1997 16:43:30 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP Address conflict

>Using netware 4.11 with all patches including the TCP03 patch.  Workstation
>using Windows 95 with Sp1 and client 32 2.12 or 2.11.
>
>I often get stations that disply the IP address conflict error when the win
>95 machine is trying to re-lease the ip address.  I saw a post on Novell's
>site about it, but the solution did not resolve my problem.  I am trying to
>use the winipcfg.exe application to release the address but it's not doing
>what Novell says it's supposed to do (Does anything from Microsoft?).
>There was a mention on the Microsoft site that Windows 95 has a 3 day
>default lease.  So my thought at this point is to change our lease time to
>something like a week or even 3 months...
-----------
	Lanalyzer. Look very carefully at what Win95 sends as a DHCP request.
It's not what RFC1531/33/41.TXT say. It is what until 10 days ago was a
draft specification, now deified as RFCs 2131 and 2132. And that means
Win95 TELLS the server what IP address it wants, very arrogantly. Like
the infamous Win95 security "feature" of remembering passwords it also
remembers an IP address and wants it back. To Win95 Ethernet hardware
addresses are a nusance at best; demand WINS identification material be
sent from client to server. You don't want to know my comments on this
to the DHCP working group meeting a couple weeks ago.

	Take up further complaints about Win95 TCP/IP behavior with MS
itself. Novell's DHCP server seems to work with both "standard" and
"history rewritten" RFCs, and now so does MS-DOS Kermit acting as a client.
What Novell's DHCP server still does not do correctly is retain statically
allocated IP assignments if the client sends a DHCP Release packet.
	Read RFCs 2131/2132 in detail, reread a few more times, look at
the LZFW packet captures, scratch head, bite tongue, carry on regardless.
	Joe D.

------------------------------

Date: Wed, 30 Apr 1997 13:08:28 +0000
From: "Robert S. Sfeir" <robert@BUYSIDE.COM>
Subject: DHCP problem fixed

I found the problem and have a solution if you're interested.

Situation 1:
It seems the problem occurs in a couple of stations log in at the same time
and the DHCP server did not have enough time to assign an IP and update
it's cache, it's assigning the same IP address to another machine and
causing the conflict. This seems like a Novell DHCP bug.

Situation 2:
The default Lease time on the windows 95 and MacOS machines is 3 days.
When set to less than 3 days there seems to be a problem with the machines
releasing the original IP address.  This however does not always happen,
and looking at the hardware and machine configuration it's very random.

So I see the problem being a combination of Novell, Microsoft and Apple.
(Probably because some RFC standards have not yet been adopted, according
to Joe D.)

Here's what I did to solve our problem:

- I increased the lease time to 183 days, since the only reason I need DHCP
is to facilitate assignment of IP addresses on the network, and since our
network is growing we've had to add routers and change our subnet twice
already, it's getting to be a pain to manage.  Giving a lease time of 6
months will hopefully also give us enough time to wait for a patch to
become available from any of those companies.

- I also started the DHCPSRVR with a -t time of 20 (load dhcpsrvr -t 20).
This means it will check for changes every 20 seconds instead of the
default 60, forcing the DHCP server to reload it's cache more often and
stopping it from assigning the same IP address to 2 different stations.

I don't know if this information is useful to you, but it works here and I
hope it will help others get around this.  I hope Novell fixes it's part of
the problem.

---------

Date: Wed, 30 Apr 1997 14:25:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP problem fixed

>I found the problem and have a solution if you're interested.
>
>Situation 1:
>It seems the problem occurs in a couple of stations log in at the same time
>and the DHCP server did not have enough time to assign an IP and update
>it's cache, it's assigning the same IP address to another machine and
>causing the conflict. This seems like a Novell DHCP bug.

	Some packet traces (LZFW) to verify this would be useful to Novell.

>Situation 2:
>The default Lease time on the windows 95 and MacOS machines is 3 days.
>When set to less than 3 days there seems to be a problem with the machines
>releasing the original IP address.  This however does not always happen,
>and looking at the hardware and machine configuration it's very random.
>
>So I see the problem being a combination of Novell, Microsoft and Apple.
>(Probably because some RFC standards have not yet been adopted, according
>to Joe D.)

	Would not surprize me. Everyone is either confused or charging in
a different direction, and the DHCP committee, being a committee, is trying
to agree with them all even if the rules move in circles.

>Here's what I did to solve our problem:
>
>- I increased the lease time to 183 days, since the only reason I need DHCP
>is to facilitate assignment of IP addresses on the network, and since our
>network is growing we've had to add routers and change our subnet twice
>already, it's getting to be a pain to manage.  Giving a lease time of 6
>months will hopefully also give us enough time to wait for a patch to
>become available from any of those companies.

	At this point I ask a silly question: why deal with dynamic pool
assignments instead of allocating static assignments forever and ever?

>- I also started the DHCPSRVR with a -t time of 20 (load dhcpsrvr -t 20).
>This means it will check for changes every 20 seconds instead of the
>default 60, forcing the DHCP server to reload it's cache more often and
>stopping it from assigning the same IP address to 2 different stations.

	See above on static.
	Joe D.

>I don't know if this information is useful to you, but it works here and I
>hope it will help others get around this.  I hope Novell fixes it's part of
>the problem.

---------

Date: Mon, 5 May 1997 20:34:20 -0700
From: John Wells <jwells@PACIFICCOAST.NET>
Subject: Re: DHCP problem fixed

>I found the problem and have a solution if you're interested.
>
>Situation 1:
>It seems the problem occurs in a couple of stations log in at the same
time
>and the DHCP server did not have enough time to assign an IP and update
>it's cache, it's assigning the same IP address to another machine and
>causing the conflict. This seems like a Novell DHCP bug.
>
>Situation 2:
>The default Lease time on the windows 95 and MacOS machines is 3 days.
>When set to less than 3 days there seems to be a problem with the
machines
>releasing the original IP address.  This however does not always happen,
>and looking at the hardware and machine configuration it's very random.
>
>So I see the problem being a combination of Novell, Microsoft and Apple.
>(Probably because some RFC standards have not yet been adopted, according
>to Joe D.)
>
>Here's what I did to solve our problem:
>
>- I increased the lease time to 183 days

Since you've solved your problem, my comments are perhaps irrelevant. But
for what it's worth:

We're using DHCP2B under 4.1, with Win95 clients. I originally set the
lease time to 16 hours, thinking that this would ensure that all leases
would expire overnight and be renewed the next morning. However, we too
ran into occasional (but very troublesome) problems with the DHCP server
giving out IP addresses that were already in use.

The conflicts seemed to happen with clients what had renewed a lease late
the previous day, and thus still "owned" at the start of the next day.
This shouldn't have caused any problem, but I shortened the lease time to
8 hours (guaranteed to require renegotiation every morning) and haven't
seen the problem since.

As I remember from my DHCP reading, even if a Win95 client asks (or
"TELLS", as Joe D. put it) to continue with its previous lease, the server
can reply "NO!", at which point the client should ask for a new IP. So
there shouldn't be a problem. Yet there was, and I can't explain it except
to say that it ceased to arise when I reduced the lease period to 8 hours.

>- I also started the DHCPSRVR with a -t time of 20 (load dhcpsrvr -t 20).
>This means it will check for changes every 20 seconds instead of the
>default 60, forcing the DHCP server to reload it's cache more often and
>stopping it from assigning the same IP address to 2 different stations.

I'd be surprised if this was the source of the problem. With our short
lease period there are about 30 stations asking for new addresses every
morning, yet no duplicates are given out. And there shouldn't be -- the
DHCP server wouldn't be doing its job if it wasn't keeping an up-to-date
record of the leases it had given out.

Anyway, whatever works.

------------------------------

Date: Thu, 1 May 1997 12:17:57 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Where to get info on BootRoms

>>>I'm considering converting some workstations that currently
>>>boot from floppy to use bootroms.
>>>
>>>Specifics:
>>>	They will use dos 6.22 and a novell menu
>>>	Also, they will need to have TCP/IP loaded
>>>
>>>Questions:
>>>	Where is a good place to get info on installing/using
>>>		these devices?
>>>	Will I have to have a DCHP server?
>>
>>Ah, that subject. Well, the matter is a bit of a mess, were the
>>truth be known. There are several kinds of bootroms, all different.
>>None has anything at all to do with DHCP; no relationship.
>
>My question on DHCP was regarding assigning IP address to the workstations.
>I'm not sure if the bootrom could handle a static IP address.
-----------
	See, I said this was Byzantine.
	Bootroms: think of them this way (which is really all they do).
The rom takes over the machine during cold boot time and sends query packets
to find a suitable bootrom-server (various protocols here). After handshakes
an image of a boot disk is dragged across the net and put into a temporary
area in memory (again, details on where and how vary). Control is then
passed to that area to continue the system boot process. Finesse is required
to get that bootrom stuff to let go of the machine and free memory.
	The disk image can hold anything you'd use to boot the machine from
a real floppy. In fact, it's made by copying just such a real floppy.
	This gives you a real mode operating system at the outset. What
happens afterward depends on what you stick on the boot floppy.

	DHCP requires a TCP/IP stack, and that requires lan drivers and
an operating system all going strong. That's not what bootroms concern
themselves with. Yes, I can imagine you read a bit of DHCP specs and noticed
the ancient "boot image file" material designed for booting real machines
in the paleolithic era. Again, a TCP/IP stack is required to deal with that,
and these days very few places use that old facility.
	Thus I recommend you separate the problems into remote booting and
DHCP, with a lot taking place between them.
	Joe D.

------------------------------

Date: Sun, 25 May 1997 11:13:17 -0400
From: "A.J. Sheehan" <ajs@CLIO.ARTS.QUB.AC.UK>
Subject: Re: dhcp-server *translated*

>How to make a redundant DHCP server in a multi-server environment (Netware
>4.10) in such a way that when one server fails (running the primary DHCP
>server) another server will take over the DHCP server task?
>BTW the ip addresses (I presume ranges) administered are static. It would help
>if tables are synchronized between the primary and secondary DHCP servers
>automaticly.

Now `automatic' switchover I don't know but running two DHCP servers using
Novell's NLM at the same time is quite okay providing the clients are getting
static addresses all the time. I do this now; one server will reply faster to
the client's request than the other so the client will regard that one as its
DHCP provider but if that fails then it will use the old address anyway for
the next three days and then do another `dhcpdiscover' and get its address
from the second server. Alternatively it can be forced to relinquish its
present address and ask for another by using the `winipcfg' utility on Win 95
clients - `renew all' - and then it will find the only DHCP server going.

------------------------------

From: "Forrest H. Swick" <fswick@unco.edu>
To: Floyd Maxwell <floyd@DIRECT.CA>
Date: Tue, 3 Jun 1997 14:17:39 -700 GMT
Subject: Additions to S.19 NOV-DHCP.DOC - Email thread on NetWare & DHCP

We are installing NT4.0 as our client workstation OS on all of our
faculty, staff and lab computers. I'm looking at assigning static IP
addresses via DHCP on all the NT clients. Up until this point we've
had the IP address assigned statically with bootp and had a bootp
server running on each server (one server for faculty and one for
students). The faculty/staff server is NW3.11 (fully patched) the
student server is INW4.11. I would like have all IP requests (either
bootp or dhcp) that were originally being sent to the NW3.11 bootp
server to be forwarded to the INW4.11 DHCP server.

Here is how our network is laid out, we are currently on a thinnet
network (pulling cable now for 10baseT) and one student lab is
10baseT.

Faculty Server NW3.11 (3 NICs)

138.86.61.1 (To repeater on top floor)
138.86.66.1 (To repeater on middle floor)
138.86.2.1 (Building BackBone and connects to Internet)

Student server INW4.11 (3 NICs) (has the DHCP server on it)
138.86.62.1 (To repeater in student lab #1)
138.86.65.1 (To hubs in student lab #2)
138.86.2.2 (Building BackBone and connects to Internet)

I've installed the INW4.11 DHCP server (and patch). I've created the
subnetwork profiles for 138.86.62.0, 138.86.65.0, 138.86.2.0,
138.86.66.0, 138.86.61.0. I've setup the Subnetwork Addresses,
Subnetwork Masks, Frame Type's, Default Router, Domain Name System
Used.

While I'm converting over to DHCP I'm assigning IP addresses both
statically and dynamically.

The IP addresses are being allocated without problems on the
138.86.2.0 subnetwork, 138.86.62.0 subnetwork, and 138.86.65.0
subnetwork.

Here is where I'm having the problem.

>From reading about bootp and DHCP I think that I need a bootp
forwarder on the server that isn't the DHCP server, the bootp
forwarder will forward on bootp and DHCP requests to the DHCP server,
which will inturn send back the IP number to either the bootp or DHCP
requester.

Following is what I did to get it to work.

I've unloaded the bootp server from the faculty server.

I then load the RESOLV.NLM (from hellsofts bootp) and is required for
the BOOTPFWD to work with the following command.

LOAD SYS:SYSTEM\RESOLV\RESOLV DM UNCO.EDU TO 15 NS 138.86.3.3 TO 30 NS
138.86.3.5

138.86.3.3 and 138.86.3.5 are the DNS server for UNC.

I then load the BOOTPFWD.NLM from
netlab1.usu.edu/pub/misc/bootp311.zip with the following command:

LOAD BOOTPFWD 138.86.2.2

The IP Number here has to the IP number that is bound to the student
server. (this is the DHCP server for the network)

Once both of these NLM's were loaded the bootp from the Windows 3.1
stations and DHCP requests from the NT stations started working.

So now all NT systems are getting their IP addresses assigned to them
via DHCP. All Windows 3.1x systems (running Novell TCPIP stack) are
getting their IP addresses assigned to them from the DHCP server.
Novell's TCPIP stack only does BOOTP requests, but the DHCP server
will return IP addresses back to both BOOTP and DHCP requests.

BOOTP and DHCP servers will not work on the same server at the same
time.

------------------------------

Date: Fri, 6 Jun 1997 18:53:20 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP question

>In TID 2919831 (DHCP: multiple subnet ranges on same segment), it says to "bind
>an IP address from each subnet range to the server's network card", then "use
>DHCPCFG to create a subnet profile for each subnet."  No real problem here I
>guess, but it just seems kind of funny to have multiple IP addresses for the
>same NIC.

	I'm pleased to see folks doing their homework before asking questions.
Good on you. Now we come to technical brass tacks. You'll need to understand
IP addressing to make sense of the instructions. A particular lan adapter
has one IP address and exists in one IP subnet. The server has one lan
adapter in an IP subnet in order to communicate TCP/IP information; it
can have many such adapters each in different subnets.
	You say nothing about needing/requiring multiple subnets on a wire,
and in must circumstances that is a very advanced and sticky thing to try.
So don't do it unless instructed to do so by your knowledgable IP responsible
person.

>Instructions for setting the Default Router say "Set the 'Default Router'
>parameter to the server's IP address for that subnet range.  Set the default
>route on the NetWare server to the IP address of the router.  This method will
>add one more hop to the IP route from the workstation out through the router
>(workstation --> server --> router instead of workstation --> router), but the
>effect should not be noticeable."

	Think about what they are saying: the client needs a gateway address,
so give it the correct one. The server is that address only if IP traffic
from clients MUST flow through it. If not then not.

>Here's my question.  This may sound silly, but I DO have to turn on IP
>forwarding on the NetWare server don't I?

	Fundamentals gain. Forwarding is routing, routing uses two or more
ports but not one port.
	Joe D.

>Also, in one of the TIDs dealing with DHCP, mention was made of a DHCP FAQ.
>I've read the DHCP info in the much quoted Novell FAQ, but this seems to imply
>there's a separate FAQ dealing only with DHCP.  Any ideas on where it might be?
>I couldn't find it.

------------------------------

Date: Sun, 22 Jun 1997 22:41:34 +1000
From: Daryl Maunder <dmaunder@MIDNIGHTOIL.COM.AU>
Subject: DHCP

>I have been trying to `hack' the DHCPTAB file but any changes I make
>do not appear to make any difference. I have noted when using DHCPCFG
>that SYS:ETC\GROUP doesn't change but it's date / time stamp is
>changed to that of DHCPTAB, also SYS:ETC\DHCPTAB.SAV is changed so
>that the section with the changed static assignment is removed and its
>date / time stamp is also changed to that of DHCPTAB. I have tried to
>`forge' similar changes and yet DHCPSRVR does not notice that any
>changes have occurred.

Try writing your changes to DHCPTAB.NEW. and see what happens. I am not as
familiar with Novell's DHCP as their BOOTP, but in bootp, the sequence is
something like:

On startup, BOOTPTAB is read into memory, and a copy made in BOOTPTAB.LWG.
The LWG file is held open in deny read mode by LWGIO.NLM the entire time it
is running, hence the date on it is not kept up do date.

Whenever a change is made, eg a new address is allocated, it is done in
memory/BOOTPTAB.LWG. The changed file is then dumped out to BOOTPTAB.  As
someone else said, once the server starts, BOOTPTAB is never read again, it
is only written to.

However LWGIO.NLM is always looking for a file called BOOTPTAB.NEW. If this
is found, it is read into memory/BOOTPTAB.LWG, and then written out to
BOOTPTAB, then deleted. This is how you can make your changes

Also, be very careful about creating other files called BOOTPTAB.XXX. LWGIO
and BOOTPD rename the file to many other things, BOOTPTAB.OLD,
BOOTPTAB.BAK, BOOTPTAB.SAV to name a few. If any of these files already
exist, it will have problems.

------------------------------

Date: Mon, 30 Jun 1997 09:07:17 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP vs. new release (OEM) WIN95 client.

>Has anyone experienced a problem with the new release of Win95 not
>getting DHCP leases from Novell's DHCP server? Has M'Soft fiddled with
>their TCP/IP (again)?
---------
	I can't say. But the situation is rather than MS has fiddled with
DHCP specs late this spring and the DHCP committee dutifully rolled over
and changed the specs orthogonally. Testing the new situation here indicates
Novell's DHCP server complies. Keep in mind that the MS mentality says the
workstation DEFINES its addresses and commands the DHCP server to comply,
rather than the other way around.
	Joe D.

------------------------------

Date: Tue, 1 Jul 1997 21:40:33 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Odd error message from DHCP server

>Server:    Compaq Proliant 2500R
>NOS:       NW 4.11 (run-time) with IWSP2
>Software:  GroupWise 5.1 and DHCP
>Other:     TCPIP.NLM 3.05 revision 5
>
>Situation:  A few weeks ago, we installed the NetWare DHCP server
>software on the above-mentioned server.  This was the one from IWSP2.
>Last week, I upgraded DHCP to the latest version (2.0I), following the
>instructions.  Everything went fine.
>
>Whether related or not, we started seeing this week a significant
>amount of messages showing on the console for the DHCP server machine.
>
>They also appear in SYS:\ETC\DHCPMAIN.LOG.
>
>The specific message is
>
>"Received packet [DHCPREQUEST] from client [NIC address here]"
>
>followed by
>
>"DHCPio_scan_bootpent() in UpdateBootpTab() returned error code -1".
>
>I have searched Novell's Web site and the Internet in vain for a
>reference to this message.  One Windows 3.1 PC whose NIC address was
>referenced had problems getting an obscure error message that would
>only show up every 10 seconds before rebooting it a few times cured it.
>
>We are gradually converting Persoft's SmarTerm for Windows on our Win
>3.1 PCs to use the DHCP server and already have our 10-15 Win95 PCs
>doing the same.
>
>Is upgrading our TCP/IP module to TCPN03.EXE the next step to take,
>followed by applying Service Pack 3?
>
>I have been slightly reluctant to upgrade to TCPN03.EXE because of an
>obscure problem that GroupWise 5.1 has with it.  We are using GW 5.1
>in client/server (TCP/IP) mode and it's been very stable thus far.
------------
	Have you tinkered with the DHCP files in sys:etc? DHCP likes to
own them completely and becomes unhappy if they are touched by humans.
	The message also says the table lookup in the DHCPTAB failed during
updating of that table, or so it seems. Oh, now wait a second. Here's
a thought... DHCP used to delete a static entry if the client released
the DHCP lease, and that's the sort of thing which leads to absent entries
and lots of changes. Alas, your log shows a DHCP REQUEST rather than a
RELEASE. Second thought then I'm done: Win95/NT like to own their addresses
and rather than do a DHCP DISCOVER (which results in OFFERs of IP addresses)
they start right off with phase II: REQUEST a particular IP number from a
cooperating DHCP server. Maybe the server isn't the cooperating agent or
maybe there is a bug in the DHCP server code when such arrogant requests
arrive unbidden.
	Joe D.

------------------------------

Date: Thu, 10 Jul 1997 10:31:32 -0400
From: Bill Lechow <blechow@OISE.UTORONTO.CA>
Subject: Re: Can DHCP handle 2 class 'C' nets

Sure it can, I've got 8 class C's administered mostly by Novell DHCP, with
one class C run by NT's DHCP - works OK. Some details that I can recall
are: use a *very recent* DHCP (v. 'i' is what I'm using, I think), also make
sure your server TCP/IP is very recent as well. Presumably you've got your
TCP/IP bound to your NIC at least twice, since your already routing.

When you configure your DHCP (with DHCPCFG.NLM), for each net:-

Identify each interface by a unique name (the default is the LAN Driver
name - add a numerical suffix to each to make the two distinctly named).

Identify each net as:- xxx.xxx.xxx.0 (the zero at the end identifies it as
a whole net).

For the default gateway or router for each net's DHCP config, use an IP
address in *that* particular network (ie. my NW server has a "native"
address in one of the 8 networks *plus* a DHCP/routing address in *each*
of the 8 networks, totalling 9 representations for the same box). Your
TCPIP configuration presumably has the higher-order gateway address
declared within it (ie. the next router up the chain from your NW router)

Use a subnet mask of 255.255.255.0 for each. I've tried playing around
with this, but it gets into some fuzzy stuff concerning "all zeros"
subnetting and limitations of INETCFG.NLM. There is a way to change the
subnet by avoiding using INETCFG and doing it via manual edits in order to
avoid a router hop, but I haven't tried it yet, as mine seems to work like
it is. The situation as is that what you (and I) have are "multi-nets"
rather than "sub-nets", so our "sub-netting" involves gathering together
more than one network, rather than chopping a single network into two or
more.

Add protocols, as required.

If you are using DNS, add "YES" to that field and insert submenu specifics.

Declare all, or a specific range of IP addresses to be automatically served.

Also, *don't let your automatically served address ranges overlap with
the scope of any other Bootp (or DHCP) servers in your network*

------------------------------

Date: Sat, 9 Aug 1997 04:16:06 +1000
From: Daryl Maunder <dmaunder@MIDNIGHTOIL.COM.AU>
Subject: Re: DHCP & NW 3.12

>Is it possible to run DHCP server on NW 3.12 server?

It certainly is. One trap is that if you extract the files from DHCP20B.EXE
onto a floppy, it MUST have a volume label of DHCPSRVR. If you extract them
onto the server, you must put them is a directory called DHCPSRVR.
Otherwise it just wont install. This is despite that fact that when you do
that, it extracts nearly all the files into DHCPSRVR / DHCPSRVR.

Someone was feeling unhappy with their job when they wrote that code I
suspect.

------------------------------

Date: Sat, 30 Aug 1997 22:23:12 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: inw4 DHCP lease expiration (when does it REALLY expire)

>How does the DHCP "expire" a lease?  The documentation (chap 12 of the
>of online docs ip administrator guide) does not give much detail.
>
>Here is some brief site config info
>about 200 class C addresses available for DHCP automatic assign (pushing
>it here) college campus with a lot of intermittent faculty users in and
>out of the office during the day so i want to make sure the leases expire
>after one hour with a one hour renewal
>
>DHCP CLIENTS:
>about 250 novell client32  DOSWIN (WFW.311 STATIONS) and 50-100 WIN95
>clients
>
>From testing it appears that once a lease expires, the IP address is still
>valid until the pool is depleted because expired addresses are still valid
>and have connectivty ( i have not actually depleted the pool yet )
>
>Is this assumption correct,????
>Does the address only become expired when the pool is depleted?

	I can't say what the DHCP server does in this case, but the rules
of the game say the client is required to release the IP number (and
hence the connection) if no extension has been negotiated. The server
thus waits for the client to release the address.

>if so, how does the DHCP server terminate the active IP address on the
>"expired" client so that is can be "reassigned" without rebooting the
>expired client

	It can't. The client has to perform that chore. Worse, the client
can renew a lease by contacting another DHCP server. The way it's done,
however, is with selective broadcasting so that the original server can
overhear the conversation. Note however that MS TCP/IP stacks have the
mistaken impression that they own the IP addresses, and they put up a
struggle to retain them even after rebooting.

>Also, how would the "expired" client intiate a new lease??
>Do they need to reboot??
>
>Please provide any insight into problems I may have with the above
>configuration or suggestion for improvement.

	These answers and more are contained in the following documents,
the list is snipped from MS-DOS Kermit v3.15, which supports both old and
"revised" methods of dealing with DHCP servers:

 *   BOOTP - Boot and DHCP Protocols, RFCs 951, 1048, 1395, 1531, 1541, 1533
 *   and successors 2131 and 2132.

	The last two RFCs, in particular, have the current rules. The rules
were rewritten (orthogonally) this spring to apparently appease MS and its
wierd way of having clients "own" IP addresses. As far as my testing goes
Novell's DHCP server plays that game properly.
	It is useful to remember that the client must cooperate because it
can continue to use that IP address as long as it wants, rules or no rules,
and the DHCP server (or a collection of them) has no way of complaining.
Your strategy would be better if lease times were say 10 minutes, because
that gives shorter dead time after a client is arbitrarily turned off/rebooted.
	Joe D.

------------------------------

Date: Tue, 2 Sep 1997 12:00:27 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP Sever and netware 3.12

>I see you guys are discussing an issue i have been trying to resolve,
>I have  a 3.12 server currently running bootp for my dos/windows 3.1
>clients.
>My problem is that I have introduced a couple of win95 clients
>(with manual IP configs)  and i  do not know how to setup the dhcp on
>my server. does any one have a step by step details on how to go
>about setting this up?
>Do i still keep my bootp service if  i were to implement dhcp?
-----------
	Very simply put: you cannot have two uncoupled agents doling out
IP addresses from the same range of IP addresses. Thus, use a DHCP or a
Bootp server, but not both at once on the same NW server (unless the IP
addresses are non-overlapping).
	Secondly, as stated this weekend, DHCP is a superset of Bootp, and
DHCP servers can respond to Bootp requests with Bootp replies. Find out by
trying it. Essentially Bootp replies are giving a non-negotiated infinite
lease IP address, and in practice that means STATIC address assignments.
There is NO WAY of knowing absolutely that a Bootp assignment has ended;
that's the reason for DHCP.
	Installation of DHCP is as per Novell instructions. I don't think
our task on the list is to read them to you. Once installed use Load DHCPCFG
to configure items. It's easier than it looks, and lots easier to do rather
than read about.
	Joe D.

------------------------------

Date: Mon, 3 Nov 1997 11:41:21 -0500
From: Eliot Ware <wares@TIDALWAVE.NET>
Subject: Re: DHCP through Cisco router

>Has anyone had success with a device getting it's IP address from
>Novell DHCP when going through a Cisco router? The Cisco does have it's
>pointer set to the Novell server for DHCP.

Are you using both a primary and secondary interface.  If so, you're going
to have some problems.  Supposedly, if you are providing DHCP only for
the network attached to the primary interface it should work.  However,
we've found that isn't always the case.

Our configuration requires us to use both the primary and secondary
interfaces and we have been unable to get the DHCP service to cross
the router.  We have been working directly with Cisco and still no go.
We finally had to go with Cisco's DHCP product (surprise, surprise)
running on an extra HP 9000 we had laying around.

---------

Date: Tue, 4 Nov 1997 00:27:26 +0001
From: KUENY Serge <skueny@HOTMAIL.COM>
Subject: Re: DHCP through Cisco router

>Has anyone had success with a device getting it's IP address from
>Novell DHCP when going through a Cisco router? The Cisco does have it's
>pointer set to the Novell server for DHCP.

Yes. It work very well.

You only need to:
1. forward the dhcp packet. (I use Helper-adress on the CISCO)
2. create the good subnet def. on DHCPCFG with the good frame.

------------------------------

Date: Tue, 4 Nov 1997 11:32:36 +1100
From: Daryl Maunder <dmaunder@MIDNIGHTOIL.COM.AU>
Subject: Re: % of volume used by Directory

>All of my users have been getting this message on my INetWare server.
>I can fix the problem by increasing the % of the volume used by directory.

Be careful. I had this problem also after installing DHCP, and kept
increasing the % of volume used by directory. It went to about 50% before
I found a TID which mentioned the problem and suggested setting SYS:ETC to
Purge Immediate. I did this and the messages disappeared. I then found an
update file NDB32I.EXE with a new NETDB.NLM which was the actual cause of
the problem. I applied it and relaxed. Then some months later, the server
started to run out of space on the SYS volume. Strangely, on a 200MB SYS
volume, there was 70MB of files, but only 10MB free. As so often is the
case, John Baird had the correct answer, the space had been eaten up by
directory entries. There is apparently no way to get it back other than to
delete and recreate the SYS volume.  So I suggest you do the following:

(1) Immediately install the NDB32I.EXE fix. (This is already in IWSP4 for
    NW4.11) Anyone running DHCP or anything else that uses NETDB should
    install this patch.

(2) Check how much space has been lost already to decide if you need to
    reinstall the SYS volume.

------------------------------

Date: Wed, 5 Nov 1997 11:55:24 +0000
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: DHCP Server 2.1K (beta)

NetWare 3.12 users who wish to try out the latest DHCP server

	ftp://ftp.novell.com/pub/netwire/nsd/dhcp21k.exe

should be aware that the following line is missing from the supplied
pscript.dat file.  Insert it, and no more hunting for the dhcp 2.0b
install files.

------------------------- cut here ----------------------------------
system,                       3X\NETDB.NLM,    N, Y, N, N, N, N, 3.12
---------------------------------------------------------------------

I think you'll need the TCPN04A and LIB312 updates applied too.

------------------------------

Date: Wed, 5 Nov 1997 17:58:07 +0000
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: TOOLBOX.NLM abends server

>'Playing' with toolbox.nlm on a fully patched non-production NW 3.12
>server has resulted in server abends under the following
>circumstances:
>
>1:  Using cron with toolbox loaded and a copy command in crontab
>    with the console screen locked in monitor resulted in
>
>    Abend: CheckKey Status called with invalid screen ID
>    Running Process: Console Command Process
>
>    Using copy.nlm (load copy ...) within crontab works fine.
>
>2:  typing 'dir sys:system\xyz.nlm' resulted in the same abend.
>
>So beware, folks.

Problem identified and solved (for the moment).

With DHCP 2.0I installed, no problems.
DHCP 2.1J: crash crash crash.
DHCP 2.1K: crash crash crash.

DHCPIO from V2.1 loaded, DHCPSRVR not loaded: crash crash crash.

DHCP 2.0I with 2.1K's netdb.nlm: no problems.

So NW 3.12 users beware.  (Don't have a 4.x server to test it on.)

---------

Date: Wed, 5 Nov 1997 17:59:50 +0000
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: DHCP Server 2.1K (beta)

>NetWare 3.12 users who wish to try out the latest DHCP server (from
>ftp://ftp.novell.com/pub/netwire/nsd/dhcp21k.exe) should be aware

that it (and DHCP21J) causes server abends when using TOOLBOX.NLM

So for the moment, just grab the netdb.nlm from the dhcp21k archive,
copy it to sys:system, and then install dhcp20i.

------------------------------

Date: Mon, 17 Nov 1997 21:25:08 -0500
From: Jerry Shenk <JAS@DECT.COM>
Subject: Re: Has anybody managed to install DHCP server on intrnetware?

>I have been trying to install novell's DHCP server with no success
>at all.
>First I tried on our 22 user server at work, it just kept saying
>that the ILS was not for an intel based system. I have also tried on my
>2 user demo version at home, where the server reboots as soon as it
>starts installing every time! arrrgh

Yea, it works great.  I've installed it quite a few times.

After you install the base novell and the MPR stuff (I don't think you
need the NIAS CD but you might) then just type 'load dhcpcfg' at the
console prompt.  That will enable you to set things up and then
'load dhcpsrvr' will load the DHCP server.  I wonder if you got things
installed right.  I did have a problem at one site with the DHCP databases
getting corrupted and I upgraded to 2.1j I think....anyway, whatever
version it was is now included with the latest patch kit.

------------------------------

Date: Wed, 3 Dec 1997 11:05:26 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell's DHCP

>Does Novell DHCP support DHCP relays.  In a campus environment with
>multiple subnets and would like to maintain 1 DHCP server.  Also, could
>anyone add some of their personal experiences with deploying Novell
>DHCP, gotcha's, cudo's, things to look out for or literature to read up
>on.
-------
	By "relays" I presume you mean forwarding a Bootp or DHCP request
through a NW server to a distant Bootp/DHCP server. The answer is yes, it
has been offered for many many years. See bootpfwd and bootpfd nlms as an
example and your NW server configuration details. Novell's DHCP server
works well here on a INW 4.11 system.
	My suggestion is to get in there and do these things, and only
afterward come back with questions on difficulties. Go for it.

------------------------------

Date: Wed, 10 Dec 1997 00:06:19 -0500
From: Michael Bell <iecis@SHORE.NET>
Subject: DHCP conflicts

I believe that DHCP 2.10K, which I picked up somewhere on the novell web site and is one version newer than 2.10J which shipped with IWSP4
resolves the win95 issue. Haven't tried it yet; too busy.

>DHCP Server release 2.10K to resolve an abend issue and assigning
>duplicate address issue.
>
>ISSUE:
>
>Issues resolved in this current release:
>
>When a host on an FDDI segment is brought up it will broadcast a DHCP
>request which is picked up by a router and forwarded to the DHCP server.
>The request will cause the server to abend running process DHCPSRVR.
>This is caused by a hardware type of 18 for FDDI within the DHCP request
>packet.  This is resolved in the current release.  The DHCP server will
>now recognize a hardware type of 18.
>
>Under certain circumstances, a client (win95) will bootup and renew the
>lease it had already.  If this happens at about the time the lease is to
>expire on the server, The dhcp server will ack the renewel to the client
>but may not re-cache the tab file just yet to put the new lease time in
>the tab file.  Before the re-cache occurs the process that checks for
>expired leases runs and deletes the old lease from the tab file.  This
>makes the addres the client just renewed available for another client to
>recieve.  This issue is now resolved.

------------------------------

Date: Thu, 11 Dec 1997 07:49:42 EST
From: "Robert L. Herron" <herronr@SMECO.COM>
Subject: DHCP and Windows 95

I've seen a couple of message on both lists about DHCP and Windows
95.  In specific, the problem is shown by Windows 95 reporting that
it detected an IP address conflict.

I was looking over John Wobus's DHCP FAQ and found the excerpt below
about Windows 95's DHCP client.  Has anyone seen the files referenced
in this excerpt?

Taken from DHCP FAQ:
(http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html)

# A specific complaint about Microsoft's Windows 95 dhcp client: it
times out its requests much more quickly than the times specified by
RFC1541 section 4.1. Among the circumstances that can turn this into a
practical problem are the latencies due to relay agents and a
server's use of ICMP echo to doublecheck the address. While it works
with Microsoft's own NT-based server, the problem prevents
interoperation with some other DHCP servers under some conditions.
Microsoft is rumored to have developed an updater named VDHCPUPD.EXE
to patch this problem, available through the following patch:

  File:                      Vdhcp.386
  File Last Modified Date:   02/12/96
  File Size:                 27,985 bytes
  File Version Information:  4.00.951

It consists of 2 files, vdhcpupd.exe and vdhcpupd.txt.

What I've heard is that it is available only on request and only for
those with support from Microsoft.

---------

Date: Fri, 12 Dec 1997 10:40:25 -0600
From: Tom Kustner <tom.kustner@EMJAY.COM>
Subject: Re: DHCP and Windows 95

Read the following link completely - it will be very helpful, I think.

   http://support.novell.com/cgi-bin/search/tidfinder.cgi?2929694

------------------------------

Date: Mon, 15 Dec 1997 20:57:46 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP and WIN95 and MAC address conflict  update

	Caution: I have attached rather lengthy material as an amplifying
reply. (jrd)

>i have found "decent" documentation as to how DHCP works in the WINDOWS NT
>server NETWORKING GUIDE that is part of the WINDOWS NT RESOURCE kit
>
>any other references like RFCs, etc  are welcome, but i have this one on my
>desk at the moment
>i dont have a packet analyzer on line at this point but am working on it as
>i am sure that would be a big help
>here are some notes on the order of requests
>
>REQUEST means from  workstation  (my defintition)
>RESPONSE means from DHCP server (my definition)
>
>DHCPDISCOVER request occurs the FIRST  time the station is booted
>DHCPOFFER response provides unleased IP address
>DHCPREQUEST request askes for the address provided in DHCPOFFER
>DHCPACK response says OK you can  have this address
>    and it updates  the DHCP server table AND the workstation updates the
>registry with the leased address
>
>here is one  problem ( remember my reference is for WINNT, but my boxes are
>WIN95 but i am extrapolating)
>i can not find this updated client address  searching the registry - maybe
>someone can
>also, where does a MAC client store this????
>
>anyway, the problem does not occur till the NEXT  time you boot the
>workstation
>at this point, here is the order of requests ( per my documentation) for a
>station with a conflict
>
>DHCPREQUEST request with the IP address from registry or wherever on
>workstation
>
>at this point i theorize because somewhere the problem occurs, but the
>following is how it should work
>
>DHCPNACK response from server saying NO that address is in use
>now the previous sequence i noted above shoud occur starting with
>DHCPDISCOVER, etc
>
>my untested theory is that the DHCPNACK is not read or accepted or responded
>to by the requesting workstation and the workstation simply assumes the
>previous address is valid
>
>of course , this all assumes that the DHCP table is not the cause of the
>problems, but if i remember correctly, we verified another MAC hardware
>address had been assigned the IP address in question
>however, i can not verify this at this moment
>
>if it was a lease time issue, regardless or whether a DHCPRELEASE request
>had been sent, i still think the problem lies with the workstation not
>accepting the DHCPNACK packet
>if the server is assigning IP address, it should be coming from the updated
>table
>
>by increasing the lease time to 30 or 360 days, the problem may be put of
>for 30 or 360 days but that defeats the purpose of DHCP
>
>however, i have not verified if a DHCPNACK was ever sent from the DHCP
>server
>if no DHCPNACK was sent, then the problem is on the server and updating is
>required
>
>anyway, that is my update from my notes
>
>sorry for providing the detail, but maybe someone will respond with explicit
>answers
>
>also, please correct any errors or omissions as i am not an expert in this
>area and am only providing a summary of my research and observations
>
>"harrington, dana" <harrinda@mi.cc.mn.us>
-----------------

	Here is an even longer technical reply, with opinions excised.
To work correctly today a DHCP server needs to be bilingual, and to hold
its tongue just right when speaking. The same is true for clients, unless
they have the MS logo.

	First, some defining docs. The 2000 series are in contradiction
with the 1500 series (the defs until this spring).
/*
 *   BOOTP - Boot and DHCP Protocols, RFCs 951, 1048, 1395, 1531, 1541, 1533
 *   and successors 2131 and 2132.
 */
	Some DHCP nomenclature:
	DHCPDISCOVER is a query broadcast by a client to find DHCP servers.
	DHCPREPLY  is from a (many) server offering IP info
	DHCPREQUEST is from a client asking to accept a particular offer
	DHCPDECLINE is from the client rejecting an offer
	DHCPACK is from the server saying agreed
	DHCPNAK is from the server saying Nope
	DHCPRELEASE is from the client returning the leased IP info
	DHCPRENEWAL is from the client asking to extend the current lease
	DHCPREBIND is from the client asking to reuse an expired lease
-----------
	Second, for reference, this is the structure of a Bootp/DHCP UDP/IP
datagram, omitting the UDP/IP portions. One element to remember is bp_ciaddr,
and it is right there that MS products cause all the trouble. Keep in mind
unicast (directed at a particular address) and broadcast addressing in this
game because they yield different results (note the RAS section in the
attached messages).

/*
 * structure for send and receives
 */
typedef struct bootp {
	byte     bp_op;         /* packet op code / message type. */
	byte     bp_htype;      /* hardware address type, 1 = Ethernet */
	byte     bp_hlen;       /* hardware address len, eg '6' for Ethernet*/
	byte     bp_hops;       /* client sets to zero, optionally used by
				   gateways in cross-gateway booting. */
	longword bp_xid;        /* transaction ID, a random number */
	word     bp_secs;       /* filled in by client, seconds elapsed since
				   client started trying to boot. */
	word     bp_flags;      /* DHCP flags */
	longword bp_ciaddr;     /* client IP address filled in by client */
				/*  if known */
	longword bp_yiaddr;     /* 'your' (client) IP address
				   filled by server if client doesn't know */
	longword bp_siaddr;     /* server IP address returned in bootreply */
	longword bp_giaddr;     /* gateway IP address,
				   used in optional cross-gateway booting. */
	byte     bp_chaddr[16]; /* client hardware address, filled by client */
	byte     bp_sname[64];  /* optional server host name, null terminated*/

	byte     bp_file[128];  /* boot file name, null terminated string
				   'generic' name or null in bootrequest,
				   fully qualified directory-path
				   name in bootreply. */
	byte     bp_vend[64+248]; /* 64 vendor-specific area + 248 DHCP */
};
--------------
	Third, some correspondence on the about-face by the standards group.

Date: Wed, 29 Jan 1997 13:42:27 EST
To:      IETF-Announce: ;
cc:      RFC Editor ,
	 Internet Architecture Board ,
	 dhcp-v4@bucknell.edu
From: The IESG
Subject: Protocol Action: Dynamic Host Configuration Protocol to Draft
	 Standard

  The IESG has approved the following documents:

    1. Dynamic Host Configuration Protocol
	[draft-ietf-dhc-dhcp-09.txt]
    2. DHCP Options and BOOTP Vendor Extensions
	[draft-ietf-dhc-options-1533update-06.txt]
    3. Interoperation Between DHCP and BOOTP
	[rfc1534]
    4. Clarifications and Extensions for the Bootstrap Protocol
	[rfc1542]

  as Draft Standards. These documents are the product of the Dynamic
  Host Configuration Working Group. The IESG contact persons are Frank
  Kastenholz and Jeffrey Burgan.
-----

Although draft-09 still contains some confusing statements on the
ciaddr field and the use of option 50 the general message is that a
DHCPRequest must contain the 'Requested IP address' option (being
equal to the yiaddr field in the DHCPOffer). This explains why the
Cisco wants to see this option and it also means that I won't have
much of a case with Cisco in changing their DHCP-implementation ;-(

Xander
< For the use of Option 50, see the source code attached below, jrd >
------- Forwarded Message

Date: Wed, 05 Mar 1997 14:49:26 -0800
From: Ted Lemon <mellon@hoffman.vix.com>
Cc:      brosnan@delni.lkg.dec.com
To:      dhcp-v4@bucknell.edu
Subject: Minutes from Connectathon DHCP meeting


After two days of DHCP Interoperability testing at Connectathon,
we have come up with a number of issues that we think may merit
clarification or further discussion.

- Backwards compatibility with RFC1541

Mike Carney mentioned that some printers and other devices have been
implemented to the RFC1541 specification rather than to the latest
IETF draft.

The significant difference between RFC1541 and dhcp-09 clients which
Mike brought up is that RFC1541 says that a client in REQUESTING state
is supposed to send the address it wants in the ciaddr field of the
DHCP packet, and not send a Requested Address option, whereas the
current draft says to send a zero ciaddr and send the requested
address in the Requested Address option.

What this means is that to a server following the current draft, an
RFC1541-compliant client will appear to go from INIT state to REBIND
state, rather than from INIT to REQUESTING.

There was some discussion about having servers simply send a DHCPACK
in this case, but the conclusion we eventually reached was that
servers shouldn't make allowances for this case, because if they do it
could cause interoperability problems in the future.

- Transaction ID on DHCPREQUEST when REQUESTING

Another issue that came up during this discussion is that the current
draft still says that during a normal boot, the DHCPREQUEST packet
from the client must contain the same transaction ID as the DHCPOFFER
packet.  It was theorized that this was an accidental formatting or
cut-and-paste error, and that this wording should be removed from the
draft.

- Running multiple subnets on the same wire

There was a great deal of discussion about what servers should do in
the presence of multiple subnets running on the same physical network
wire.   It turns out that of the four vendors that admitted to
providing any support for this problem, three different methods were
being used.   It was decided that an informational draft should be
produced describing these current practices.   I will be producing
such a draft and sending it to the other vendors for review.

- When to send DHCPNAK

There was some discussion as to when it is appropriate to send a
DHCPNAK message.  The current draft only specifically mentions two
cases where it is appropriate: when the client is in the REQUESTING
state and requests an address that the server is unable to provide,
and when the client is in the INIT-REBOOT state and requests an
address which is either on a subnet other than the one to which the
client is connected, or is for a lease that has expired.

Mike Carney observed that it is possible for a laptop which has been
sleeping to lose track of time, and therefore to try to enter the
RENEWING or REBINDING state late, such that it is asking for a lease
that has expired.   If a server that owns the address being requested
is unable to renew the lease, it makes sense for it to return a
(broadcast) DHCPNAK.   The client would then immediately deconfigure
the IP address and return to the INIT state.

The other case where it makes sense to send a DHCPNAK is when the
client is in the REBINDING state and broadcasts a DHCPREQUEST with a
ciaddr that is inappropriate for the network to which it is attached.
At that time, it would speed up the address reacquisition process if
the server were to send a DHCPNAK to the client and the client were to
deconfigure its address and return to the INIT state.

There was also some disagreement on what to do in the event that a
client enters the RENEWING or REBINDING states late.   One possible
response would be to simply send a DHCPNAK, forcing the client to
return to the INIT state and reacquire its address.   The
expressed justification for this is that in a situation where there
are fewer addresses available to be leased than there are clients
wanting to lease them, it is desirable to force clients to compete for
addresses, and that forcing a late renewer to return to the INIT state
would facilitate this.

The opposing viewpoint was that forcing a client into the INIT state
when it's not necessary may cause it to lose connections, even if it
eventually reacquires the same IP address, and can cause a needless
delay during the reboot process.  It was also observed that it would
be possible to use an adaptive algorithm that can determine whether or
not competition is needed.  If it is needed, a DHCPNAK is sent; if
not, the renewal is simply acknowledged as it normally would be if the
client had not delayed its renewal.

- Unicast DHCPDISCOVERs

In section 4.4.4, the current draft mentions that if the client knows
the DHCP server's address, it can unicast the DHCPDISCOVER message.
Nobody in the meeting quite understood when this would make sense -
isn't the point of DHCPDISCOVER that you *don't* necessarily know what
network you're connected to and thus don't know the DHCP server's
address?

- RAS servers

Several vendors produce something called a Remote Access Server (RAS),
which acts as a proxy to acquire addresses and configuration
information for clients that it supports.   The details of what a RAS
server's clients look like and do aren't important - what is important
is that the RAS server is a single device on the network, and yet it
needs to perform the DHCP protocol on behalf of more than one client.

Existing RAS servers accomplish this by faking up a hardware address
and a Client Identifier for each address they ask for, and hoping that
this doesn't cause too much confusion for the server.   The DHCP
server then treats the RAS server as if it is several different unique
clients.   The DHCPDISCOVER and DHCPREQUESTs from the RAS server needs
to be broadcast.

At the meeting, Mike brought this up as an undesirable situation, and
I suggested that instead of faking out the DHCP server in this way,
the RAS server should behave as if it is relaying DHCP packets to and
from a DHCP client - it should put its own IP address in the giaddr
field of every request it generates, and unicast all such packets.

It was generally agreed that even if the RAS server is on the same
network as the DHCP server and is acquiring addresses for that net,
existing DHCP server implementations would correctly forward their
responses to port 67 at the IP address specified in the giaddr field.

Although it will appear to the DHCP server that various DHCP clients
are communicating with it using the RAS server as a relay agent, the
RAS server will actually be performing the DHCP protocols as a proxy
for the clients - no actual relaying of packets will be done.   This
changes RAS server implementation somewhat, but greatly reduces the
burden on the DHCP server implementor, who is currently being exposed
to more details about what the RAS server is doing than is entirely
appropriate.   It also improves efficiency somewhat, since the RAS
server no longer broadcasts its DHCP packets.

One way in which this complicates RAS server implementation is that
once a client has been successfully configured in proxy, it may want
to send a DHCPINFORM to the server to get more network parameters, and
the RAS server must successfully relay this packet, rather than
treating the server's response as a spurious proxy response.
	<rest omitted>
---------

	Fourth, I think after a few rereadings you get the idea that
MS products wish to remember their IP number and demand it back when
they return to the air. This is in contravention to the notion of
leasing an address and returning it when done, and never attempting
to "own" it. But what are standards bodies for if not to be committees?

	Fifth. So far as I can surmise Novell's current DHCP servers
operate fine with either way of doing business.

	Lastly I'll spare your eyes and mail reader about 500 lines of
dense C code on how to make Bootp and DHCP requests and negotiations in
either 1541 or 2131 fashions. It's part of MS-DOS Kermit v3.15. But to
satisfy curiosity here are 38 lines where ciaddr and Option 50 appear in
opposition by DHCP version. This is just a small piece of the whole.

	sbp->bp_op = BOOTREQUEST;
	sbp->bp_htype = (byte)(arp_hardware & 0xff); /* hardware type */
	bcopy(eth_addr, sbp->bp_chaddr, MAC_len); /* hardware address */
	sbp->bp_hlen = (byte) MAC_len;          /* length of MAC address */
	sbp->bp_xid = xid;                      /* identifier, opaque */
	sbp->bp_ciaddr = htonl(my_ip_addr);     /* client IP identifier */
	*(long *)&sbp->bp_vend[0] = VM_RFC1048; /* magic cookie longword */

	if (bootmethod == BOOT_DHCP)            /* DHCP details */
		{
		sbp->bp_vend[4] = DHCP_COMMAND; /* option, DHCP command */
		sbp->bp_vend[5] = 1;            /* length of value */
		sbp->bp_vend[6] = DHCPREQUEST;  /* Request data */
		sbp->bp_vend[7] = OPTION_END;   /* end of Options */
		if (DHCP_state == DHCPDISCOVER) /* if first probe */
			{
			sbp->bp_flags = htons(1); /* set DHCP Broadcast bit */
			sbp->bp_vend[6] = DHCPDISCOVER; /* DHCP server discov*/
			}
		if (DHCP_state == DHCPREQUEST)  /* if Request, not Renewal */
			{
			sbp->bp_vend[7] = OPTION_SERVERID; /* server id */
			sbp->bp_vend[8] = 4;            /* length of value */
			*(long *)&sbp->bp_vend[9] = htonl(DHCP_server_IP);
			sbp->bp_vend[13] = OPTION_END;  /* end of Options */
			if (use_RFC2131)          /* if not using RFC1541 */
				{
				sbp->bp_ciaddr = 0; /* no client identifier */
				sbp->bp_vend[13] = 50;  /* Requested IP Addr*/
				sbp->bp_vend[14] = 4;   /* length of value */
						/* our IP address goes here */
				*(long *)&sbp->bp_vend[15] = htonl(my_ip_addr);
				sbp->bp_vend[19] = OPTION_END;
				}
			my_ip_addr = 0;     /* now forget IP from DISCOVER */
			}
		}

	You might guess I spent a little time on this matter, with the stds
folks and others this spring and making code work both ways.
	Joe D.

------------------------------

Date: Tue, 16 Dec 1997 17:56:45 -0600
From: Karl Klemm <khklemm@AMOCO.COM>
Subject: Re: DHCP and WIN95 and MAC address conflict  update

>Joe,
>
>You say that "Novell's current DHCP servers operate fine", but my
>experience, like Dana Harrington's, is of getting a lot of Windows 95
>"The system has detected a conflict for IP address xxx.xxx.xxx.xxx"
>errors. What I _need_ to know is how to overcome this small(!) difficulty.
>
>Maybe the MS client _is_ broken, but it's the one I'm stuck with :-(
>* Is there a new, unbroken, MS client available for W95?
>  If so, where?
>* Is there a new version of the Novell DHCP server available
>  which works around this behaviour?
>  If so, where?

We were getting these types of errors frequently when we first started
migrating to Win95.  It appears that a majority of our problem was in
the lease duration.  We moved from BOOTP to DHCP seemlessly and left
the default 3 days.  As a user would leave for the weekend, they would
power down (being energy conscious, of course).  At that point, the
server's clock keeps counting down the lease.  At T1, he gets no
renewal request.  At T2, he gets no request.  Finally, the lease
expires (about Sunday afternoon if the user left Thursday evening).
The customer fires up on Monday morning, their workstation try to
reuse the address, the server has already given it out, and the
workstation moans about it -- and you get a couple of phone calls
about it.

We found that setting a lease duration of 21 days on every segment
helped (after everyone had gotten a renewal and the new duration).
This took care of 99%+ of our problems including long weekends and
vacations.  (The only ones that still had trouble were those that took
extremely long vacations... and I guess there is a cost to everything
:).  This method may use a few more IP addresses than a shorter lease
duration but the cut down in phone calls was well worth it.  (BTW, my
company thought the same thing about an NT DHCP server.  The big
problem we saw is that it doesn't "automatically" honor BOOTP requests
from WIN3.x workstation like Novell's.  While we could preallocate
them, it wasn't worth typing in 2,000+ addresses in hopes that that
product might resolve the problem).

---------

Date: Tue, 16 Dec 1997 17:37:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP and WIN95 and MAC address conflict  update

>We were getting these types of errors frequently when we first started
>migrating to Win95.  It appears that a majority of our problem was in
>the lease duration.  We moved from BOOTP to DHCP seemlessly and left
>the default 3 days.  As a user would leave for the weekend, they would
>power down (being energy conscious, of course).  At that point, the
>server's clock keeps counting down the lease.  At T1, he gets no
>renewal request.  At T2, he gets no request.  Finally, the lease
>expires (about Sunday afternoon if the user left Thursday evening).
>The customer fires up on Monday morning, their workstation try to
>reuse the address, the server has already given it out, and the
>workstation moans about it -- and you get a couple of phone calls
>about it.

	That's a pretty good description of affairs. The Win95 station seems
both unable and unwilling to play the DHCP game and thinks it permanently
owns the IP address. When told the address is reassigned it apparently is
unable to ask for another. Petulant child. This is broken DHCP behavior and
you can yell at Microsoft, with packet traces in hand.
	Locally I discourage dynamic IP address pools. They end up being
trouble. Yes, there are many situations where  # clients > # addresses
and dynamic pools are the only solution.
	Joe D.

------------------------------

Date: Tue, 16 Dec 1997 21:18:21 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DHCP conflicts and joe doupnik extended reply

>First I wish to thank Joe D for this extended reply and the time taken to
>generate it
>
>Some of the detailed code is beyond my level of skill and understanding
>(at least at this point ) but I am studying the document carefully as
>I know a strong knowledge of DHCP is required at my site

	Here I think you make a very good point: we need to understand
DHCP well enough to diagnose situations with the aid of a packet monitor.
We may not like what we find, but at least we understand the situation.

>it is clear this is a subject  of interest as many of us  attempt to reduce
>IP addressing tasks through the use of DHCP servers in mixed environments

	Having lived through the experience of redesigning my DHCP/Bootp
code as the standards folks changed their thinking I can say the whole
matter is initially a muddle to understand. But I like to simplify and
say things in words, so I create scenarios and see who says what to whom
and how.
	In the case at hand we ask: how does a client reclaim an expired IP
address, according to the rules and according to the wire monitor? DHCP
Option 50 comes into play, as a way the client can say I request this
specific IP address, pretty please. The informal notes in my msg yesterday
help ellucidate this technical detail.
	When all is said and done, and the commercial apps still don't wish
to cooperate, we get down to permanent leases, static assignments. Static may
be quicker and easier in the end where the environment permits.
	A last word. I haven't checked the current Novell DHCP server, but
earlier versions would delete static assignments if the client returned
a lease early (early means returned it at all). Keep an eye peeled. Here's
the comment in my code on that item:

/* Release DHCP granted IP information. Skip if DHCP ACK has not been
   received or if lease time is infinite (to help Novell's DHCP v2.0
   from clobbering itself with erasure of permanent assignments).
*/
void
end_bootp(void)
{
	...

	Joe D.

------------------------------

Date: Wed, 17 Dec 1997 10:43:53 -0500
From: "Benninger, Paul" <pbenninger@INTEGON.COM>
Subject: Re: DHCP conflicts and joe doupnik extended reply

>My point is, it appears BOTH APPLE and MICROSOFT have deviated from
>the concept of leasing addresses, so please hold both vendors accountable.

This is not totally true -- at least in Micro$oft's case.  A Micro$oft
DHCP server will lease addresses for administrator-specified periods
of time.  So you can set the server to free up a lease if the workstation
that originally had it doesn't retain it or request it for X amount of time.

If it doesn't ahdere to the actual standard, it's still a good idea,
IMHO.  It gives you a good balance between a static address, and a
dynamically assigned address.  In other words, you have some predictibility
as to what your IP address will be.  My NT workstation has had the same
IP address since it was converted to DHCP (about six months ago). However,
if I take a week's vacation, I'll probably pick up a different one when
I get back.

------------------------------

Date: Wed, 17 Dec 1997 15:57:45 +0000
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: DHCP and WIN95 and MAC address conflict  update

>Joe,
>
>You say that "Novell's current DHCP servers operate fine", but my
>experience, like Dana Harrington's, is of getting a lot of Windows 95
>"The system has detected a conflict for IP address xxx.xxx.xxx.xxx"
>errors.  What I _need_ to know is how to overcome this difficulty.
>
>Maybe the MS client _is_ broken, but it's the one I'm stuck with :-(
>* Is there a new, unbroken, MS client available for W95?
>  If so, where?
>* Is there a new version of the Novell DHCP server available
>  which works around this behaviour?
>  If so, where?

Try ftp://ftp.novell.com/pub/netwire/nsd/dhcp21n.exe

Note it's a hidden file but if you type the above url into NetScape
it will retrieve it.

Our workaround was to set long lease times so that if people went off
sick or on holiday the lease would still be valid.

------------------------------

Date: Fri, 19 Dec 1997 06:22:21 -0500
From: Jerry Shenk <JAS@DECT.COM>
Subject: Re: DHCP and WIN95 and MAC conflicts

>I am trying to be a respectful internet administrator as far as class C
>addresses, but at this point it may be easier to simply aquire another
>class C address space and use long lease times

It's not really being 'wasteful' for IP addresses to have a long lease
time...I've been setting the lease up for 60 days after this problem
surfaced at one of my clients and the problem is gone.  Even then, it was
VERY spotty and seemed to happen only on Monday mornings which fits well
with the default lease time that a Win95 machine asks for.

From a security standpoint, you might want to consider putting your users on
the 10.0.0.0 network which is defined in the RFCs as being for internal use
only.   Then do network address translation (Border Manager includes that).

------------------------------

Date: Mon, 5 Jan 1998 22:25:21 +0000
From: Richard Letts <r.j.letts@SALFORD.AC.UK>
Subject: Re: DHCP Routing.

>All:  I have DHCP running, but it does not route to other segments.  For
>instance, the dial up segment does not get assigned addresses.  I read
>the documentation from Novell and it mentioned running bootpfwd.nlm.
>When I ran it, it gave an error about not finding the bootp port.  I am
>running Intranetware 4.11.
>
>My question:  Do you have to run bootp as well as DHCP in order for the
>bootpfwd.nlm to work?  Hopefully there is a better way.  TIA,

Bootp is the precedessor of DHCP. In order for DHCP to work you need to
have EITHER a DHCP server on each network, or the bootp/dhcp forwarder
loaded on the fileservers to forward bootp/dhcp requests to a single
DHCP/bootp server.

[difference: with bootp there is not notion of a 'lease lifetime' the
client can use the IP address for as long as it likes. with DHCP the
client is 'leased' the address for a specific ammount of time, and has to
renew the lease before it expires. the protocols should be
forward/backward compatable, except if you're running win95]

To help further we need a network diagram (ascii will do) showing the
locations of the client, DHCP server, and nearby IP routers [or NetWare
servers acting as IP routers]
[sorry for any mispellings, but I'm editing this over an IP link with 40%
packet loss and it's painful]

------------------------------

Date: Sat, 10 Jan 1998 23:21:19 +0000
From: Richard Letts <r.j.letts@SALFORD.AC.UK>
Subject: Re: DHCP lease questions

>I am installing DHCP which has prompted several questions:
>
>1)  It appears that workstations that have successfully received IP
>Addresses, immediately  lose those addresses if the granting DHCP server
>goes down for any reason, without notification to the user.

Huh? a DHCP server is required to save the lease information to stable
storage in case it fails. The clients know they have been leased an
address and the server is expected to remember this.  If the server is
not remembering, report it as a bug to whoever you got the server off.

>In other words, it appears that, if workstations stay up during the
>night and server maintenance includes downing the DHCP server, those
>workstations will lose there IP addresses without any warning, etc. to
>the users.

Do they immediately loose their IP addresses, or just after the addresses
have expired?

If you have the lease set to less that 3 days then the Microsoft clients,
eg Win95 or winNT, have problems and don't try to renew the leases soon
enough. setting the lease to longer (eg a week) will let them renew the
leases before they expire.

[NB I don't use Novell's DHCP server, I use the ISC one on a UNIX machine
beacuse I can link it to the DNS with a perl script. I'm really waiting
for Novell to release their integrated DHCP/DNS/NDS servers outlined at
brainshare last year]

---------

Date: Sun, 11 Jan 1998 20:22:54 -0500
From: Darwin Collins
Subject: Re: DHCP lease questions

It depends on your client IP stack.

For those with the TCP/IP driver that comes with VLMs, it supports only
BootP, and not DHCP.  (hence, try to do a permanent lease of the IP from
a DHCP server)

Well, when you load the TCPIP.EXE and it can not contact the DHCP server,
then, it will not initialize its TCPIP stack.

Win95/NT will be ok.  Until approx. 50% (depends on the setting) of your
DHCP lease period.

So... basically... if you have VLM/TCPIP...  don't take your server down
unless you need to.

For the Win95/NT, set a 180 day or longer DHCP lease period, if you can
afford it. (have ample supply of IP addresses)

------------------------------

Date: Wed, 14 Jan 1998 13:44:28 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Netware Connect Crashes Server

Once again, we all need to remember that Novell rarely makes statements
suggesting we NOT run two such applications on one server unless they
know that there are problems doing so.

The fact that one thing works in one place is a grace and not a rule.

I always suggest accepting that Novell do know what they are saying when
they ask not to run DHCP and NWC on the same server.

Also to be remembered, is that if you have to call Novell support
direct, they ask a few questions, such as.... Are all patches applied,
What applications are running, What platform of Hardware....If any of
those answers don't fit the criteria, such as....NOT all patches are
applied, You are running multiple software on the server where one or
more are said not to work, or the Hardware platform is not approved
(these are all eg's of course), You won't get much help if any other
than to be told to fix it and call them again afterwards if you still
have the problem.

There are enough problematic issues to deal with, without bringing some
more about by not following simple, if not always easy to follow rules.

------------------------------

Date: Thu, 15 Jan 1998 10:18:21 -0500
From: Doug Summers <dsummers@SHERIKON.COM>
Subject: Re: Monitoring users who change IP Addresses... -Reply

>>There are several users here changing their IP addresses, so they
>>believe they can not be caught, and proceed to internet sites which
>>management deems inappropriate...
>
>Sounds like a job for (trumpets blaring..)  BorderManager!

One way we do that here is to use DHCP and assign lease times of
0 hours. As soon as a user would change their address it would
change back upon restart. Also, if you remove access to the Network
control panel and registry tools it would further your effort.

------------------------------

