On Tue, May 20, 2014 at 12:02:47PM +0200, Stefan Sperling wrote:
| On Tue, May 20, 2014 at 11:33:48AM +0200, Paul de Weerd wrote:
| > As can be seen, the host part of the link-local address doesn't
| > resemble the lladdr at all. This isn't a problem for outgoing
| > connections, but when using SLAAC the global unicast address that is
| > assigned is now suddenly different from what it used to be (so from
| > what is in DNS), so I can't easily connect to my machines over IPv6
| > anymore.
|
| I"m seeing this, too (-current built last Sunday).
|
| What strikes me is that the link-local address contains the same
| bits as the SLAAC address (lines aligned to make this easier to see):
|
| lladdr 40:61:86:85:70:71
| inet6 fe80::b020:cbf3:e5a1:d0d3%re0 prefixlen 64 scopeid 0x1
| inet6 2001:67c:1407:10:b020:cbf3:e5a1:d0d3 prefixlen 64 autoconf pltime
604638 vltime 2591838
| ^^^^^^^^^^^^^^^^^^^
|
| The first address is supposed to be the link-local address based
| on the MAC (40:61:86:85:70:71), but somehow contains the SLAAC
| address bits... ???
The SLAAC address isn't the source of these bits, they're generated
and then used as the eui64 host part of both the link-local and the
SLAAC address.
Previously, the SLAAC address would also have the same bits as the
link-local address (but then they'd both be based off the lladdr with
the 6th bit inverted and 0xfffe inserted in the middle).
This should be the behavior that you get with mpi's diff (thanks,
Martin!). I'm updating my tree and will compile a new kernel shortly
but won't be able to reboot and test until tonight.
Cheers,
Paul 'WEiRD' de Weerd
| On another box which runs a snapshot built April 29 this still
| works as expected:
|
| lladdr 00:00:24:c9:2f:01
| inet6 fe80::200:24ff:fec9:2f01%vr1 prefixlen 64 scopeid 0x2
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
