lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47335258.4000806@hp.com>
Date:	Thu, 08 Nov 2007 13:15:52 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	Jiri Bohac <jbohac@...e.cz>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org, kkeil@...e.de
Subject: Re: Why does a connect to IPv6 LLA address fail ?

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
>> destination.
> 
> Good point.
> 
> What's confusing is that connect(2) fails even if the host itself has the 
> specified address. This isn't necessary.

Yes and no.  Since linux doesn't have the concept of default zone, we have
to fail, because from the perspective of the kernel, the address was not
fully specified.  OTOH, since this is our address, we 'could' have all
the info.

The problem is that this verification happens before we hit the routing logic.
It's an explicit check the if the sin6_scope_id is not set and we are not bound
to an interface, it's an error.

> 
> What's even more confusing is that the kernel doesn't seem to honor the 
> interface in all cases: with
>    fe80::20f:20ff:fe3b:e9c3 on eth0 and
>    ::1 on lo,
> I get the following:
> 
>   ping6 fe80::20f:20ff:fe3b:e9c3		fails with EINVAL
>   ping6 fe80::20f:20ff:fe3b:e9c3%eth0		succeeds

Yes, but if you run a capture, you'll see the packet on loopback.  That's
because you have a route to this address.

>   ping6 fe80::20f:20ff:fe3b:e9c3%lo		succeeds

Yes, same thing.  Routing code takes care of it.

> 
> At least the last ping should fail, shouldn't it?

No, because both pings really go over loopback.  You are on the same system
and have 'local' routes for those addresses:
  ip -6 r l t local

> 
>> A different and some might say 'better' alternative is to define a
>> default link.  Thus when the zone id is not specified the default is used.
>> This will work fine for link-scoped addresses.  A default zone would also
>> need to be defined for other scopes as well.  That's just one idea.
> 
> I think at least for host with only one link (in addition to loopback), 
> selecting that link for non-local addresses would make sense.
> 

Yes, you could do that.  Or you can push the interface check to the routing code
and do some logic to see if you can "select" an interface.

-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ