[Dibbler-devel] git version 26.07 10:00 works (mostly)

Tomek Mrugalski thomson at klub.com.pl
Tue Jul 26 14:31:07 CEST 2016

On 26/07/16 11:12, Mircea Ciocan wrote:
> Hello Tomasz, I have seen a lot of activity on the git during the
> evening and I've made today a quick test and compared with the version
> from 25.07 (yesterday), this version now works in the "normal" conditions.
Yup. I recently (couple weeks ago) merged huge patch for better smart
pointer casts. It required update in tons of places in the code and some
of those changes introduced a bug in IA_NA parsing code. I spent an
evening yesterday on this and think this particular issue is fixed.
> The curious thing is, in the case of duplicate DUID there is no
> rejection message to the server anymore ( but also no crash ;), and
> the duplicate address seem to be accepted by the client, but is
> actually not added to the interface (this is somehow a good thing to
> not have a duplicate address in the network but the client is still
> unreachable and there are no other requests made).
There seems to be a problem with how the software tells the kernel to
add an address. I don't know why. The code was working for 10 years or
more. Anyway, the code for manipulating addresses comes from the ip tool
from iproute2 package. Dibbler uses ancient version of that code that I
imported many, many years ago. I'm in the process of importing the
recent (4.3.0,
version of it. When adding manually (e.g. ip addr add 2001:db8::1/64 dev
eth0), it works and then detects DAD correctly. When called from within
dibbler code, it doesn't.
> So it seems that we're on a good track here, it will be so nice if we
> can restore the proper logic to have the duplicate address being
> rejected, and maybe the DHCP server will pull another address from the
> pool.
The first problem - dibbler not parsing responses - is fixed. The second
problem is that for some reason adding addresses stopped working. Once
that is fixed, I can fix the logic.
> If there is anything that I can do to assist you, please let me know,
> I'm more of an embedded C guy and my C++-fu is not so stong but I can
> still help you with debugging and testing in unusual situations.
Sure. I have an uncommitted version with iproute2 4.3.0 code. I hope to
merge it today, but can't make any promises (my girlfriend has a small
celebration today). This is something I'd love to have some help from
you. The code uses netlink socket to configure an address. I *think* it
does exactly the same as the code in ip tool, but surely there has to be
some subtle difference.
> I would have loved to take part last week hackathon, but unfortunately
> I had to spend the time in a hospital with a sick family member, I
> hope you guys had fun.
I hope your family member will get well soon. The hackathon ended up
focusing on implementing YANG/NETCONF interface for Kea, the other DHCP
server I'm involved in. It was fun to learn a completely new technology.

> Anyway, here is the relevant part of the client log when it detects a
> duplicate address, is seen that it grudgingly accepts it, but it is
> not actually set to the interface:
> 2016.07.26 10:50:09 Client Debug     Initialising link-state detection
> for interfaces: eth3/30
> 2016.07.26 10:50:09 Client Notice    CONFIRM support compiled in.
> 2016.07.26 10:50:09 Client Info      Creating SOLICIT message with 1
> IA(s), no TA and 0 PD(s) on eth3/30 interface.
> 2016.07.26 10:50:09 Client Debug     Sending SOLICIT(opts:1 3 39 8 1 )
> on eth3/30 to multicast.
> 2016.07.26 10:50:09 Client Debug     Sleeping for 1 second(s).
> 2016.07.26 10:50:09 Client Debug     Received 80 bytes on interface
> eth3/30 (socket=6, addr=fe80::3e97:eff:fe86:9a7d).
> 2016.07.26 10:50:09 Client Info      Received ADVERTISE on
> eth3/30,trans-id=0x4d7412, 3 opts: 3 1 2
> 2016.07.26 10:50:09 Client Debug     Not executing external script
> (Notify script disabled).
> 2016.07.26 10:50:09 Client Debug     Sleeping for 1 second(s).
> 2016.07.26 10:50:10 Client Info      Processing msg
> (SOLICIT,transID=0x4d7412,opts: 1 3 39 8 1)
> 2016.07.26 10:50:10 Client Info      Creating REQUEST. Backup server
> list contains 1 server(s).
> 2016.07.26 10:50:10 Client Debug     Advertise from Server
> ID=00:01:00:01:1f:29:df:44:3c:97:0e:86:9a:7d, preference=0.[using this]
> 2016.07.26 10:50:10 Client Debug     Sending REQUEST(opts:1 3 39 1 2 8
> ) on eth3/30 to multicast.
> 2016.07.26 10:50:10 Client Debug     Sleeping for 1 second(s).
> 2016.07.26 10:50:10 Client Debug     Received 80 bytes on interface
> eth3/30 (socket=6, addr=fe80::3e97:eff:fe86:9a7d).
> 2016.07.26 10:50:10 Client Info      Received REPLY on
> eth3/30,trans-id=0xce9f43, 3 opts: 3 1 2
> 2016.07.26 10:50:10 Client Notice    Address 2001:1:8::9/128 added to
> eth3/30 interface. <<< This is a LIE !!!
Yup. I took a look at this yesterday, but failed to find the problem.
Something fishy is going on in ipaddr_add_or_del() function in
Port-linux/lowlevel-linux.c. In particular, there is rtnl_talk function
called and it seems to return status 0. What dibbler does should be
functional equivalent of calling command:

ip addr add 2001:1:8::9/128 dev eth3 valid_lft 2000 preferred_lft 1000
> 2016.07.26 10:50:10 Client Notice    Server set T1 and T2 to 0.
> Choosing default (50%, 70% * prefered-lifetime): T1=27000, T2=37800
> 2016.07.26 10:50:10 Client Debug     Not executing external script
> (Notify script disabled).
> 2016.07.26 10:50:10 Client Debug     Sleeping for 3 second(s).
> 2016.07.26 10:50:13 Client Debug     Sleeping for 1 second(s).
> 2016.07.26 10:50:14 Client Error     DAD inconclusive. Unable to
> dermine 2001:1:8::9 address state. Assuming NOT TENTATIVE.
Yup. Since the address was not added to the interface, this call also
fails. It tries to find the address and check whether it's duplicated or

Finally, on a slightly related note, when I wrote the initial Dibbler
code, the status of the address could be determined by tentative flag.
It could mean one of two things. First, when address was just added and
DAD is in progress. Second, if the duplicate was detected, the address
remained in tentative state. Nowadays kernel has separate flag for
signaling that address is duplicated. I don't have my dev system
accessible right now, so can't tell what what exactly the name, but it
was something like dadfailed. I think the code should be updated to use
that flag, rather than tentative. So is_addr_tentative() should be
updated as well. But this seems to be a low priority for now.

Ok, that's it for now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://klub.com.pl/pipermail/dibbler-devel/attachments/20160726/b27ca332/attachment.html>

More information about the Dibbler-devel mailing list