Received: by oss.sgi.com id ; Tue, 29 Aug 2000 15:53:04 -0700 Received: from [212.84.236.131] ([212.84.236.131]:26116 "HELO convergence.de") by oss.sgi.com with SMTP id ; Tue, 29 Aug 2000 15:52:43 -0700 Received: (qmail 2287 invoked by uid 100); 29 Aug 2000 22:52:59 -0000 Date: Wed, 30 Aug 2000 00:52:59 +0200 From: Felix von Leitner To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: [2.4.0test6] IPv6 link-local TCP still slightly broken Message-ID: <20000830005259.A2246@convergence.de> Mail-Followup-To: Felix von Leitner , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing The application that triggers this problem is npoll (to be found at http://www.fefe.de/ncp/). Basically, it consists of two parts, npush and npoll. npush will send IPv6 multicast packets to the network and npoll will use them to see where it has to connect(). The multicast packets are send out on eth0, and (I had a bug report about this earlier) the IPv6 scope_id now signals the interface as eth0, too. npoll then tries to connect to my own link local address on eth0. This fails horribly. Here is a tcpdump: 00:14:38.506140 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: S 3266263975:3266263975(0) win 32144 00:14:38.506180 fe80::260:67ff:fe33:d15b.8002 > ::1.32796: S 3269115708:3269115708(0) ack 3266263976 win 32144 00:14:38.506191 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: R 3266263976:3266263976(0) win 0 00:14:41.502287 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: S 3266263975:3266263975(0) win 32144 00:14:41.502316 fe80::260:67ff:fe33:d15b.8002 > ::1.32796: R 1025851588:1025851588(0) ack 1 win 0 Due to another bug that I haven't isolated yet, the packets are actually received twice by tcpdump. I edited the duplicates away. Please note that this traffic was captured off lo, not eth0, so although I specified eth0 as interface, the SYN packet is sent over lo. And, the source IP is ::1, the loopback IP. Apparently, through some major kludge somewhere, the kernel is allowed to send a packet from an eth0 link-local address to ::1 on lo, but the receiver code understands that this can't be right and tries to reset the connection. Please note that the reset is apparently never seen by the other side, though, so the connect() system call eventually times out. This is just a dump of the first seconds. I don't think that "::1" is the proper source address. This should be changed to fe80::260:67ff:fe33:d15b, my link-local address. Then, the lo code should be changed to allow packets to and from any of my link-local addresses. Any comments? Does this make any sense? I am not sure if my resubscription on linux-kernel worked (haven't received a confirmation yet), and I am not subscribed to netdev yet, so please carbon-copy comments to me. Thanks. Felix