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

Tomasz Mrugalski thomson at klub.com.pl
Wed Jul 27 22:25:42 CEST 2016

On 27.07.2016 20:43, Mircea Ciocan wrote:
> Hello Tomasz, as expected the fact that the address duplicate address
> can't be assigned to the interface is indeed a kernel issue, when the
> assignment fails I have the following messages in the system log:
> Jul 27 14:20:53 kernel: [782286.129796] IPv6: eth3: IPv6 duplicate
> address 2001:1:8::10 detected!
> Jul 27 14:20:54 kernel: [782286.698279] IPv6: eth3: IPv6 duplicate
> address 2001:1:8::10 detected!
> Jul 27 14:20:57 kernel: [782289.705480] IPv6: eth3: IPv6 duplicate
> address 2001:1:8::10 detected!
> ....
> So I think that my hypothesis, that the kernel does not allow the DAD
> invalid address to be set is confirmed.
Am afraid that theory is incorrect. Try to add it manually with:
ip addr addr 2001:1:8::10 dev eth3

and the addition *will* succeed. If you run "ip addr list" in a quick
loop, you will notice that the address is being added with tentative
flag set and then after a second or so dadfailed flag is added.

> Now why the set function doesn't return an error cod is not clear to me
> but that#s another story.

Dibbler assumes in several places that the address it added is present
on the interface and I don't want to change that logic. We need to find
out why the address assignment works when called from ip from command
line, but fails when called from dibbler code.

> But the most important issue right now is the segfault when accessing
> the Options member via that list iterator. It seems that once this
> object is invalid segfaults happens.
> I have no clue why it becomes invalid, if is a list issue (most likely)
> but once it gets in this state is game over.
I suspect that the checkDecline logic is broken and somehow it puts a
NULL pointer on the declined IAs list. Have you had a chance to apply my
verbose patch:

I suspect it will show that

> One other thing is that considering addresses with unknown status as
> tentative was in my case a good idea, I don't think is altogether a
> better option but it will be cool that in a future release to have it as
> a configurable parameter.
Not really. The fact that dibbler thinks it added an address, but the
address was not really added is a bug. Adding configuration knobs on top
of that bug would make it an ugly kludge. This is not something I would
like to have. Especially that we don't know why the assignment failed,
so it could possibly fail in other cases and have false positives as a

> So if you have any idea how can we do something about this Options
> member and his unhappy list I will be so happy ;).
We'll get to that once the failed address assignment problem is
resolved. I don't want to skip any steps, sorry. If I jump in and solve
the checkDecline bug, I'm afraid the underlying problem would remain


More information about the Dibbler-devel mailing list