[Dibbler] Funny behavior with 1 address per client limitation...

Tomasz Mrugalski thomson at klub.com.pl
Fri Aug 3 11:08:03 CEST 2007


On Thu, 2 Aug 2007 somebody known as Jim Rayno wrote:

> Here is my server.conf file:

> I start the server, then start the client.  DHCP exchanges occur, the
> client receives
>
> the address (from the specified pool) and configures the interface ok.
> I then stop the
>
> client and start the client again.  At this point, the client gets into
> an exchange with
>
> the server and never is able to acquire another address
Hmmm, seems like server bug. If by stopping client you mean "execute 
RELEASE/REPLY" exchange, your client should have 0 addresses assigned 
(from the server's perspective). Or if you killed your client (without 
releasing address) then, when your client restarts, server should provide 
the same (already assigned from the server's perspective) address.

So definetely, it's a server bug.

> and the client is logging
> "Unable to send REQUEST. There are no backup servers left." message.
This message is not very clear. It should state that "communication with 
current server (for some reason) failed. I'd like to start communicating 
with other servers, but there are no backup servers left (this was the 
only one, which sent ADVERTISE message, probably)".


> believes it (the client) still is in ownership of the first address
> assigned to it during
> the first run.  The two stay in this request, deny loop indefinitely.
In general, server should reassign the same address. In fact, after long 
talks with Bernie Volz (DHCPv6 spec coauthor) I think that this parameter 
has to be reimplemented. In general, I thought that when client sends 
another REQUEST for the same IA, it asks for another address. However, 
proper way of asking for additional address is to send REQUEST with 
different IA. So there is no way that amount of addresses assigned to ona 
IA is increased, so the checking routines should check number of IAs 
rather than number of addresses. To make long story short - another part 
of the code to rewrite :(

> Also I can see the
> entry in the server-AddrMgr.xml file, and it always reports its as
> NOTCONFIGURED, even during successful configuration.
States in the AddrMgr are little messed up. I'm thinking about removing 
them completely and storing the state in the CfgMgr only. But yes - you 
are right, that is another bug.

Cheers,
Tomek



More information about the Dibbler mailing list