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

Mircea Ciocan mirceac at gmail.com
Thu Jul 28 15:12:45 CEST 2016


Dear Tomasz, I will do some unit tests with the lowlevel-linux.c module,
practically a mini ip command, because the most baffling stuff is not that
it fails, but that it most of the time succeeds ( in normal situations )
and sometimes fails.
I will try to make it succeed all the time, even if the address fails the
DAD it should still be there on the interface with that dadfail flag set
but not missing.
I will use first the old code that compiles on my machine and then the new
code.
Strange (for me) situation I've encountered during the experiments:

I have set a host with a static IPv6 that was getting the final flag and
all OK, then on the other host I've set the same IP and expecting to fail,
strangely enough, it got the final flag and previous host got the dadfail
flag, is this normal or is there any order or whoever finishes the DAD test
first get the fail flag ?

Maybe you can tell me if you know more details.

Now back to the little unit test for the low level linux stuff.

 Best regards, MC




On Wed, Jul 27, 2016 at 10:25 PM, Tomasz Mrugalski <thomson at klub.com.pl>
wrote:

> 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:
> https://gist.github.com/tomaszmrugalski/5d7afaa5efc042af2861b61b2bc5e574
>
> 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
> result.
>
> > 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
> unsolved.
>
> 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/20160728/fe892cc6/attachment.html>


More information about the Dibbler-devel mailing list