---------------------------------------------------------- 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 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 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 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 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" 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 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 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 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 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 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 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 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" 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 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 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 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" 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" To: Floyd Maxwell 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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" 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 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 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" ----------------- 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 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. --------- 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 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 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 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" 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 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 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 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 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 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 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. ------------------------------