Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

[Andrew Morton]

(Added netdev cc)

Felix von Leitner <felix-linuxkernel@fefe.de> wrote:
>
> Now about IPv6: npush and npoll are two applications I wrote.  npush
> sends multicast announcements and opens a TCP socket.  npoll receives
> the multicast announcement and connects to the source IP/port/scope_id
> of the announcement.  If both are run on the same machine, npoll sees
> the link local address of eth0 as source IP, and the interface number of
> eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> Since this has been broken in different ways for as long as I can
> remember in Linux, and I keep complaining about it every half a year or
> so.  Can't someone fix this once and for all?  IPv4 checks whether we
> are connecting to our own address and reroutes through loopback, why
> can't IPv6?
> 

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> 
> (Added netdev cc)
> 
> Felix von Leitner <felix-linuxkernel@fefe.de> wrote:
> >
> > Now about IPv6: npush and npoll are two applications I wrote.  npush
> > sends multicast announcements and opens a TCP socket.  npoll receives
> > the multicast announcement and connects to the source IP/port/scope_id
> > of the announcement.  If both are run on the same machine, npoll sees
> > the link local address of eth0 as source IP, and the interface number of
> > eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> > Since this has been broken in different ways for as long as I can
> > remember in Linux, and I keep complaining about it every half a year or
> > so.  Can't someone fix this once and for all?  IPv4 checks whether we
> > are connecting to our own address and reroutes through loopback, why
> > can't IPv6?

afaik, this problem is still open.  If you have time, please provide
additional info for the net developers.  Maybe the source to npoll anbd
npush?

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

[Johannes Stezenbach]

Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > 
> > (Added netdev cc)
> > 
> > Felix von Leitner <felix-linuxkernel@fefe.de> wrote:
> > >
> > > Now about IPv6: npush and npoll are two applications I wrote.  npush
> > > sends multicast announcements and opens a TCP socket.  npoll receives
> > > the multicast announcement and connects to the source IP/port/scope_id
> > > of the announcement.  If both are run on the same machine, npoll sees
> > > the link local address of eth0 as source IP, and the interface number of
> > > eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> > > Since this has been broken in different ways for as long as I can
> > > remember in Linux, and I keep complaining about it every half a year or
> > > so.  Can't someone fix this once and for all?  IPv4 checks whether we
> > > are connecting to our own address and reroutes through loopback, why
> > > can't IPv6?
> 
> afaik, this problem is still open.  If you have time, please provide
> additional info for the net developers.  Maybe the source to npoll anbd
> npush?

Grab the ncp package from http://www.fefe.de/ncp/, or more specifically
ftp://ftp.fu-berlin.de/unix/network/ncp/ncp-1.2.3.tar.bz2.

It's a very useful and handy tool for pushing around data within
a LAN of a small workgroup, one guy does "npush foo" and yells
at the intended recepient "do npoll". The first one to do
it wins and gets foo ;-)

Johannes

Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

[Johannes Stezenbach]

Johannes Stezenbach wrote:
> Grab the ncp package from http://www.fefe.de/ncp/, or more specifically
> ftp://ftp.fu-berlin.de/unix/network/ncp/ncp-1.2.3.tar.bz2.
> 
> It's a very useful and handy tool for pushing around data within
> a LAN of a small workgroup, one guy does "npush foo" and yells
> at the intended recepient "do npoll". The first one to do
> it wins and gets foo ;-)

In case that description sounded too silly: The essential feature
of ncp is that it requires no configuration or installation of a
server daemon, and you don't even need to worry about host names or the
IP address of the source or destination machine. Just hook two computers
to the same network and you're ready to npush/npoll. Similar to
netcat + tar, but way more convenient.

Johannes

[PATCH] [IPV6] Fix address/interface handling according to the scoping architecture (is Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050311173308.7a076e8f.akpm@osdl.org> (at Fri, 11 Mar 2005 17:33:08 -0800), Andrew Morton <akpm@osdl.org> says:

> Felix von Leitner <felix-linuxkernel@fefe.de> wrote:
> >
> > Now about IPv6: npush and npoll are two applications I wrote.  npush
> > sends multicast announcements and opens a TCP socket.  npoll receives
> > the multicast announcement and connects to the source IP/port/scope_id
> > of the announcement.  If both are run on the same machine, npoll sees
> > the link local address of eth0 as source IP, and the interface number of
> > eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> > Since this has been broken in different ways for as long as I can
> > remember in Linux, and I keep complaining about it every half a year or
> > so.  Can't someone fix this once and for all?  IPv4 checks whether we
> > are connecting to our own address and reroutes through loopback, why
> > can't IPv6?

I think this has been there for long time (maybe since 2.4...).

With the following patch, I can connect local link-local address.
- Change incoming interface according to the scoping architecture
- Choose source address on appropriate interface, according to the
  scoping architecture.

Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>

===== net/ipv6/ip6_input.c 1.23 vs edited =====
--- 1.23/net/ipv6/ip6_input.c	2005-03-10 14:12:11 +09:00
+++ edited/net/ipv6/ip6_input.c	2005-03-24 17:49:15 +09:00
@@ -71,10 +71,18 @@
 		goto out;
 	}
 
-	/* Store incoming device index. When the packet will
-	   be queued, we cannot refer to skb->dev anymore.
+	/*
+	 * Store incoming device index. When the packet will
+	 * be queued, we cannot refer to skb->dev anymore.
+	 * 
+	 * BTW, when we send a packet for our own local address on a
+	 * non-loopback interface (e.g. ethX), it is being delivered
+	 * via the loopback interface (lo) here; skb->dev = &loopback_dev.
+	 * It, however, should be considered as if it is being
+	 * arrived via the sending interface (ethX), because of the
+	 * nature of scoping architecture. --yoshfuji
 	 */
-	IP6CB(skb)->iif = dev->ifindex;
+	IP6CB(skb)->iif = skb->dst ? ((struct rt6_info *)skb->dst)->rt6i_idev->dev->ifindex : dev->ifindex;
 
 	if (skb->len < sizeof(struct ipv6hdr))
 		goto err;
===== net/ipv6/addrconf.c 1.134 vs edited =====
--- 1.134/net/ipv6/addrconf.c	2005-03-15 14:21:11 +09:00
+++ edited/net/ipv6/addrconf.c	2005-03-24 11:52:17 +09:00
@@ -942,7 +942,7 @@
 int ipv6_get_saddr(struct dst_entry *dst,
 		   struct in6_addr *daddr, struct in6_addr *saddr)
 {
-	return ipv6_dev_get_saddr(dst ? dst->dev : NULL, daddr, saddr);
+	return ipv6_dev_get_saddr(dst ? ((struct rt6_info *)dst)->rt6i_idev->dev : NULL, daddr, saddr);
 }
 
 

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

IPv6 has trouble assigning an interface

[Felix von Leitner]

I'm using stock 2.6.11.7 now.

Here is an strace of some piece of code of mine:

socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [12884901889], 4) = 0
bind(3, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
setsockopt(3, SOL_IPV6, IPV6_MULTICAST_LOOP, "\1", 1) = 0
[...]
sendto(3, "ncp-lowfat-1.2.2", 16, 0, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "ff02::6e63:7030", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)

ff02 is a link-local multicast address.  I've bound to ::.  How can this
fail?  link-local should always work, even if no routes are set and no
router has been found.

Felix

Re: IPv6 has trouble assigning an interface

[Pekka Savola]

On Mon, 25 Apr 2005, Felix von Leitner wrote:
> Here is an strace of some piece of code of mine:
>
> socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [12884901889], 4) = 0
> bind(3, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> setsockopt(3, SOL_IPV6, IPV6_MULTICAST_LOOP, "\1", 1) = 0
> [...]
> sendto(3, "ncp-lowfat-1.2.2", 16, 0, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, "ff02::6e63:7030", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
>
> ff02 is a link-local multicast address.  I've bound to ::.  How can this
> fail?  link-local should always work, even if no routes are set and no
> router has been found.

Umm.. link-local unicast and multicast both require that you specify 
the interface, because otherwise it's ambiguous -- how could the 
kernel know which interface should be used to send the packet?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: IPv6 has trouble assigning an interface

[David Stevens]

It's failing because it doesn't know what interface you want to send on, 
and link-local
addresses don't narrow that down any. If you bind to a specific IPv6 
address, it'll use
that interface (as a work-around). Adding a route for the multicast 
address may also
work (haven't tried). I'd expect using IPV6_MULTICAST_IF would work, but a 
quick
test appears that it doesn't. Specifying a sin6_scope_id as the interface 
index on the
sendto() is another way of specifying the device that doesn't appear to 
work.

So, there may be a bug. Note that if you bind to "::" without doing 
anything else and
send to a link-local address, it can't know what interface you want to 
send on by
the destination, so your program won't control which interface it'll send 
on. Doing
that by binding to a specific interface's IPv6 address works for me (the 
failure is
in assigning the source address when it isn't known). Specifying the 
device in
other ways ought to work, too, so I'll look into this a bit more (as will 
others, no doubt).

                                                        +-DLS

> ff02 is a link-local multicast address.  I've bound to ::.  How can this
> fail?  link-local should always work, even if no routes are set and no
> router has been found.

> Felix

Re: IPv6 has trouble assigning an interface

[Felix von Leitner]

Thus spake Pekka Savola (pekkas@netcore.fi):
> >Here is an strace of some piece of code of mine:
> >
> >socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
> >setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [12884901889], 4) = 0
> >bind(3, {sa_family=AF_INET6, sin6_port=htons(8002), inet_pton(AF_INET6, 
> >"::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> >setsockopt(3, SOL_IPV6, IPV6_MULTICAST_LOOP, "\1", 1) = 0
> >[...]
> >sendto(3, "ncp-lowfat-1.2.2", 16, 0, {sa_family=AF_INET6, 
> >sin6_port=htons(8002), inet_pton(AF_INET6, "ff02::6e63:7030", &sin6_addr), 
> >sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign 
> >requested address)
> >
> >ff02 is a link-local multicast address.  I've bound to ::.  How can this
> >fail?  link-local should always work, even if no routes are set and no
> >router has been found.
> Umm.. link-local unicast and multicast both require that you specify 
> the interface, because otherwise it's ambiguous -- how could the 
> kernel know which interface should be used to send the packet?

OK for unicast.
But multicast?  I expected link-local multicast to send on _all_
interfaces if I don't specify one.

Felix

Re: IPv6 has trouble assigning an interface

[Kyle Moffett]

On Apr 26, 2005, at 02:10, Felix von Leitner wrote:
> OK for unicast. But multicast?  I expected link-local multicast
> to send on _all_ interfaces if I don't specify one.

This statement makes no sense.  "link-local ... on all interfaces".
Isn't "link-local" supposed to mean that the address is unique and
available only on that interface (ethernet segment)?  It's possible
to get the _same_ link-local address on multiple ethernet segments,
so in that case, where would you send the packet???  When you send
link-local packets, you must specify the link to which it is local.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: IPv6 has trouble assigning an interface

[David Stevens]

netdev-bounce@oss.sgi.com wrote on 04/27/2005 03:57:05 PM:

> On Apr 26, 2005, at 02:10, Felix von Leitner wrote:
> > OK for unicast. But multicast?  I expected link-local multicast
> > to send on _all_ interfaces if I don't specify one.

(I didn't see the article this is quoting-- apparently wasn't CC-ed
to "netdev" as the original was).
        Multicasting doesn't work that way. Multicast group memberships
are per-device (whether or not they are link-local). If you join
the same group address on two different devices, they'll only be the
same group if there are multicast routers on the two links connecting
them in the same multicast routing hierarchy. With a scope broader
than link-local, and a multicast router on that link, the packets
can be forwarded to other links, but they won't be forwarded to
every host on the internet in that group (!), and there are sometimes
good reasons for having different partitions of the same group
within a single organization. So, the same group number on two
different links is not necessarily the same group. It depends
entirely on whether the two groups have common multicast routers
with no policy restricting forwarding for that group between them.
        This is how IPv4 multicasting works, too. You join a group
on a particular device.

                                                                +-DLS