netdev - Re: specifying scopid's for link-local IPv6 addrs

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: <20070725021505.62a646ea.billfink@mindspring.com>
Date:	Wed, 25 Jul 2007 02:15:05 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	Sridhar Samudrala <sri@...ibm.com>
Cc:	Rick Jones <rick.jones2@...com>,
	Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: specifying scopid's for link-local IPv6 addrs

On Tue, 24 Jul 2007, Sridhar Samudrala wrote:

> On Tue, 2007-07-24 at 10:13 -0700, Rick Jones wrote:
> > > Rick,
> > > 
> > > I don't see any way around this.  For example, on one of my test
> > > systems, I have the following link local routes:
> > > 
> > > chance% netstat -A inet6 -rn | grep fe80::/64
> > > fe80::/64                                   ::                                      U     256    0        0 eth0
> > > fe80::/64                                   ::                                      U     256    0        0 eth2
> > > fe80::/64                                   ::                                      U     256    0        0 eth3
> > > fe80::/64                                   ::                                      U     256    0        0 eth4
> > > fe80::/64                                   ::                                      U     256    0        0 eth5
> > > fe80::/64                                   ::                                      U     256    0        0 eth6
> > > 
> > > So if I want to run a link local test to fe80::202:b3ff:fed4:cd1,
> > > the system has no way to choose which is the correct interface to
> > > use for the test, and will give an error if the interface isn't
> > > specified. 
> > 
> > Yeah, I was wondering about that.  I'm not sure if the attempts on "those other 
> > OSes" happened to involve multiple interfaces or not.  Even so, it "feels" 
> > unpleasant for an application to deal with and I wonder if there is a way for a 
> > stack to deal with it on the application's behalf.  I guess that might involve 
> > some sort of layer violation between neightbor discovery and routing (typing 
> > while I think about things I know little about...)
> > 
> > Is there RFC chapter and verse I might read about routing with multiple 
> > link-local's on a system?
> > 
> > > You must explicitly specify the desired interface.  For example,
> > > on my test system, the correct interface is eth6 which is interface 8
> > > (lo eth0 eth1 eth2 ... eth5 eth6).  Here is an example nuttcp test
> > > specifying interface 8:
> > > 
> > > chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8
> > >  1178.5809 MB /  10.02 sec =  986.2728 Mbps 12 %TX 15 %RX
> > > 
> > > nuttcp uses getaddrinfo() which parses the "%<ifindex>" field,
> > > and then copies the sin6_scope_id from the res structure to the
> > > server's sockaddr_in6 structure before initiating the connect().
> > 
> > OK, I'll give that a quick try with netperf:
> > 
> > [root@...pc106 ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M -m 64K 
> > -H fe80::207:43ff:fe05:9d%2
> 
> We can even specify the interface name instead of the interface index
>    <link-local>%ethX
> 
> getaddrinfo() uses if_nametoindex() internally to get the index.
> 
> Thanks
> Sridhar

Cool!  That's much easier and works great.  :-)

chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%eth6
 1178.5468 MB /  10.02 sec =  986.3239 Mbps 13 %TX 15 %RX

Still learn something new every day.  Now if I just could remember
it all when I needed it later.  :-)

						-Thanks

						-Bill
-
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