[Dibbler-devel] Dibbler client crashes if address is duplicate
thomson at klub.com.pl
Fri Jul 22 16:29:03 CEST 2016
On 22/07/16 11:45, Mircea Ciocan wrote:
> Hello all, I have deployed the dibbler client in a moderately large
> network using ISC DHCP server version 4.1.1 and for some weeks all
> worked OK, but now I have the following problem:
> In some specific situations the dibbler-client dies without a trace, and
> the only messages I have in the DHCP server log:
> Jul 21 09:59:24 dhcpd: Client XXXX releases address YYYY
> Jul 21 10:00:20 dhcpd: Client XXXX reports address YYYY is already in
> use by another host!
> Jul 21 10:32:39 dhcpd: Client XXXX reports address YYYY is already in
> use by another host!
> Afterwards, the dibbler-client suddenly dies, and the device is left
> without any valid IPv6 address, thus is becoming unreachable :(.
What do you mean by "dies"? Segfaults or terminates silently?
This should be relatively easy to reproduce: configure your server with
a very small pool of one address and then configure manually this
address on the server's interface. The client will get this address and
should trigger the DAD routine.
> As far as my research was able to discover could be a situation similar
> to this one:
> While having duplicate DUIDs in a network is a bad thing, but sometimes
> this is happening and the client service should not crash but reject the
> address, this seem to be a bug.
True. Out of curiosity, what was the reason for duplicate DUIDs to
appear? Cloned VM, cheap NICs that happen to have the same address or
> Tomasz or anybody that knows the code base organisation, could you
> kindly point me to the C++ module that deals with this condition to try
> to see what is happening and what leads to the crash ?
The actual determination if address is duplicated is check in
is_addr_tentative function in Port-linux/lowlevel-linux.c. You can grep
*.cpp sources to find where this function is called from. The areas you
should look at will are:
ClntCfgMgr/ClntCfgMgr.cpp:230 and 842
If dibbler-client segfaults, you can set ulimit -c 9999999999 and then
dibbler will dump the core, which can be inspected with gdb. If that is
the case, please send me the backtrace of it (bt command in gdb).
If dibbler quits silently, there may be another cause. Dibbler uses
imported code from iproute tools that I don't fully understand. There's
a lot of exit() calls in it. One possibility is that those pieces of the
code are somehow triggered.
More information about the Dibbler-devel