9e4d9402   
   From: Simon.Richter@hogyros.de   
      
   Hi,   
      
   On 2010年06月16日 00:39, Albert Manfredi wrote:   
      
   > The DHCP server or servers then send back their DHCP Offer message,   
   > and the client picks the one it prefers. This DHCP Offer message   
   > includes the Server ID for every responding server. So now the client   
   > has the Server ID it needs.   
      
   > NOW the client issues a DHCP Request, using the appropriate Server ID.   
      
   Not yet. The server ID is only used for renewals; if I omit the option    
   from the ACK packet (assuming the MUST in the table is wrong and the MAY   
   in the explanatory text is right), then the ISC client will renew via a    
   broadcast, while uDHCPc will ignore the ACK and time out.   
      
   I can see either behaviour being correct, given that the RFC seemingly    
   contradicts itself.   
      
   The server as currently coded works fine for serving the local subnet,    
   or for serving any subnet as long as a default route option can be    
   added. This might not always be the case, and I'm wondering whether to    
   treat this as a configuration error (I'd hand out leases that the    
   clients cannot renew), or whether the behaviour of the ISC client is    
   indeed correct.   
      
   If I understood correctly, configuration using a relay agent will skip    
   the agent after the client has received an address, which means the    
   agent need not be reachable via unicast from the client network, but    
   only from the side of the actual server.   
      
   The actual server code already works fine for all cases except for this    
   one. The easy way out would be to treat it as a configuration error, and   
   I'm very inclined to do so, but I'd like to be sure that it indeed is one.   
      
       Simon   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)