Karsten Keil wrote:
>
> OK I run into this issue while running the TAHI testsuite. The test is as
> follows:
>
> Check 03:
> DNS Address: fec0::9
> Candidate Source Addresses: fec0::1(SS) or LLA(LS)
> Destination Address List: 3fff::2(GS) or fe80::2(LS)
> Result: fe80::2 (src LL
On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote:
> Andreas Gruenbacher wrote:
> > On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> >> The reason is that 2 different hosts may have the same link-local
> >> address as long as they are on different links. If the sender is
> >
Andreas Gruenbacher wrote:
> On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
>> The reason is that 2 different hosts may have the same link-local
>> address as long as they are on different links. If the sender is
>> connected to both links then it may send the packet to the wrong
>> des
On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> The reason is that 2 different hosts may have the same link-local
> address as long as they are on different links. If the sender is
> connected to both links then it may send the packet to the wrong
> destination.
Good point.
What's co
Jiri Bohac wrote:
> Hi,
>
>> For this it create a socket for datagram and
>> protocol IPPROTO_IP and then try to connect it with the destination
>> address. This fails in the case of a LLA, because connect returns EINVAL,
>> since here is no device bind to this socket at this time.
>
> [snip]
>
Hi,
> For this it create a socket for datagram and
> protocol IPPROTO_IP and then try to connect it with the destination
> address. This fails in the case of a LLA, because connect returns EINVAL,
> since here is no device bind to this socket at this time.
[snip]
> Why do we have this check in i
Hi,
currently I do some cerification test for IPv6 with the TAHI ct testsuite.
With the default-addr-select tests for compliance with RFC3484 here are
FAILs with Destination Address Selection Check Rule 2(Prefer matching
scope). Yes I know that Destination Address Selection is done in glibc,
but i