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

Mircea Ciocan mirceac at gmail.com
Tue Jul 26 17:41:11 CEST 2016

Dear Tomasz, thanks a lot, happy birthday to your gf from a one of your
software users, maybe we should meet on the next hackathon, hopefully you
will still have interest in this project because I consider it very nice
and now that the code base gets updated it should be useful for a long time.

I'm eager to test the version with the latest iproute code addition and if
the code works in normal and whatever test situation you can think off,
then a new release should be done to have a stable reference code base.

I don't know if after the code reorganisation the patch that I've sent you
some while ago is still needed or has been already integrated in the code
base because this was solving a real life normal operation scenario so
please don't forget about it.

This being said, please let me know when you have committed the new source
code so I can test it and thanks once more.

 Best regards, MC

On Tue, Jul 26, 2016 at 2:31 PM, Tomek Mrugalski <thomson at klub.com.pl>

> 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,
> http://archive.ubuntu.com/ubuntu/pool/main/i/iproute2/iproute2_4.3.0.orig.tar.xz)
> 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
> not.
> 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.
> Tomek
> _______________________________________________
> Dibbler-devel mailing list
> Dibbler-devel at klub.com.pl
> http://klub.com.pl/cgi-bin/mailman/listinfo/dibbler-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://klub.com.pl/pipermail/dibbler-devel/attachments/20160726/fbf96348/attachment-0001.html>

More information about the Dibbler-devel mailing list