Conference turris::digital_unix

I would have expected the server to NAK the request, causing the client
to send a discover message.  I've passed your question on to the folks
who wrote joind to ask them.

If joind is started out of /etc/inetd.conf then it should shut itself down
after 15 minutes, if it does not see any traffic on the BOOTP server port.
This is tunable; see the man page for joind.  If it's started by hand or
as a daemon out of an rc file then it does not shut down automatically.


	-- Farrell

[Posted by WWW Notes gateway]

I got this response back regarding .0:

Here is the answer to your question.
The "pool" is a range of addresses, belonging to the server in question,
that can be re-allocated to different clients. There is nothing to prevent
the user creating a (clientID,IPaddr) binding where the IPaddr is *NOT*
in the pool. Once that binding has been created, and assuming it belongs to
the server, that client will *always* get the IP address designated.

The server behaves differently for "pool" addresses and "non-pool"
on receipt of a DHCPRELEASE. For pool addresses the server releases
them (in the DB they are actually expired immediately rather than
deleted). But a RELEASE of a non-pool address has no effect at all.
This is so that you, as sysadmin, can continue to configure certain
machines with the same IP addresss even if those machines run the
DHCP protocol and think that they release the address.

Your colleagues inquiry is similar. It is true that the 10.10.10.10
address was originally in the pool, but once the pool is changed
JOIN will not know of that. From the point of view of joind, the
binding may have been created "by hand".

The way to solve this problem is to explictly delete the binding
from the GUI.


[Posted by WWW Notes gateway]

    Thanks Farrell,
    
    But I can see nowhere in the GUI where the 10.10.10.10 address may have
    been defined. Nor does it jump out at me as to which of the many node
    or server parameters might indicate retention of a specific network
    address.
    
    If I look in /var/log, I see that the client has specifically requested
    addresss 10.10.10.10.  What would force a client to ask for a specifi
    address or if it is the server that is tell the client to continue to
    make this request then which parameter needs to be changed ?
    
    Thanks,
    Al
    

This is part of how DHCP works.

The client maintains state of what it was previously given by the server.
It has the option of broadcasting a REQUEST message to ask the server
to re-confirm the validity of that state.  The client isn't obliged to
start from scratch (that is, broadcast a DISCOVER message.)

joind will send back an ACK, for the reasons explained in .2

If the client had moved to a different subnet or if the requested address
was otherwise invalid, the server would NAK the client, forcing it
back to the DISCOVER state.


At this point you may wish to have a peek at two things.  One is
RFC-1541, Dynamic Host Configuration Protocol.  Note that RFC-1541 is
being revised and that there are important differences between this
and the current draft.  Here are some pointers:


A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Dynamic Host Configuration 
 Working Group of the IETF.                                                

Note: This revision reflects comments received during the last call period.

       Title     : Dynamic Host Configuration Protocol                     
       Author(s) : R. Droms
       Filename  : draft-ietf-dhc-dhcp-09.txt
       Pages     : 45
       Date      : 12/27/1996

The Dynamic Host Configuration Protocol (DHCP) provides a framework for 
passing configuration information to hosts on a TCP/IP network.  DHCP is 
based on the Bootstrap Protocol (BOOTP) [7], adding the capability of 
automatic allocation of reusable network addresses and additional 
configuration options [19].  DHCP captures the behavior of BOOTP relay 
agents [7, 21], and DHCP participants can interoperate with BOOTP 
participants [9].                                                          

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-dhc-dhcp-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-09.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email protected]. In the body type: 
     "FILE /internet-drafts/draft-ietf-dhc-dhcp-09.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

[Posted by WWW Notes gateway]

    Thanks Farrell for th pointer.  I've pulled down the rfc and begun to
    read through it.
    
    the question is now, now to tell dhcp through xjoin to either operate
    in "dynamic allocation" mode or to give a client a spcific address.
    
    It is not at all obvious as to how to accomplish this.  IT is also
    very difficult to understand which file(s) xjoin is objecting to when
    it doesn't like an entry as it does not call out the file by name.
    I've tried to assign a specific IP address to a specific client, but
    xjoin either ignore the add or objects to the address format or
    something.
    
    It appears that we've purchased a GUI that out does us in terms of
    poor GUI design!
    
    Al