[Dibbler-devel] Adding an IPv6 that is already assigned to other host.

Mircea Ciocan mirceac at gmail.com
Fri Jul 29 14:23:54 CEST 2016


One more update:

If I force the valid to be forever value (0xFFFFFFFF) the address is added
with the following flags:

# ./ip addr list dev eth3
34: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
    link/ether a4:f7:d0:00:0d:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth3
       valid_lft forever preferred_lft forever

*inet6 2001:1:8::10/128 scope global tentative dadfailed        valid_lft
forever preferred_lft 53995sec*
    inet6 fe80::a6f7:d0ff:fe00:d5d/64 scope link
       valid_lft forever preferred_lft forever

Now the very curious thing, possible a bug: the DECLINE message is only
send if the address is not into the client leases file, if it already is
then is added and NO duplicate address is detected (no checks or DHCP
server requests are done after the address is set, including when I cut the
physical link and restore it).
Even if the interface has the *dadfailed* and *tentative* flags set they
are never read again and the address is considered valid during refresh.
Please have a look I don't think that this is the right behaviour.

 Best regards and have a nice week-end, MC







On Fri, Jul 29, 2016 at 11:48 AM, Mircea Ciocan <mirceac at gmail.com> wrote:

> Dear Tomasz, after simplifying a bit the function that manages addresses
> and doing some unit testing (program available at request to not pollute
> the list) I have encountered the following situation:
>
> - Adding an OK address works with whatever values for valid and preferred
> values.
>
> - Adding a DAD failed address (already allocated)  works ONLY if the valid
> time is set to *forever* (0xFFFFFFFF), preferred time does not seem to
> matter.
> When adding with the ip addr add.. command if the valid and preferred
> times are not explicitly mentioned they are set by default to *forever *this
> is why the ip command seem to work.
>
> The bad part is that the call to rtnl_talk function returns OK even if the
> address is not actually added :-(( and we have to take a decision regarding
> on how to deal with this situation, maybe reading the address back to see
> it it is there ?
>
>  Please advise what do you think is the best solution now that this ugly
> and uncommented Russian spaghetti code (ip code) is still fresh in my mind,
> I would rather not touch it anymore if it's not need it.
>
> Did you have any success with the DECLINE message ?
>
>
> Best regards, MC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://klub.com.pl/pipermail/dibbler-devel/attachments/20160729/0a015b4e/attachment.html>


More information about the Dibbler-devel mailing list