[Dibbler] Funny behavior with 1 address per client limitation...
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.
More information about the Dibbler