netdev
[Top] [All Lists]

Re: [Fwd: Problem with dual IPv4/IPv6 connect]

To: Pekka Savola <pekkas@xxxxxxxxxx>
Subject: Re: [Fwd: Problem with dual IPv4/IPv6 connect]
From: Tom Marshall <tmarshall@xxxxxxxx>
Date: Fri, 19 Nov 2004 10:43:29 -0800
Cc: davem@xxxxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.61.0411190904580.6216@netcore.fi>
References: <20041118184950.GB3972@real.com> <Pine.LNX.4.61.0411190904580.6216@netcore.fi>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
> I'd suggest you resend it to netdev, but also attach a minimal, 
> trivial test case .c file which allows anyone to easily experiment 
> with the behaviour, test a fix, etc.

Recap of the issue:

  s = socket(AF_INET6, SOCK_STREAM, 0)
  connect(s, [fec0::203:baff:fe88:5a15]:1554) => EINPROGRESS
  Put socket in select's write set
  Kernel sends TCPv6 SYN
  Kernel receives ICMPv6 Time Exceeded (routing error)
  Socket becomes writable
  getsockopt(s, SO_ERROR) => EHOSTUNREACH
  connect(s, [:ffff:192.168.168.241]:1554) => ECONNABORTED

Okay I've attached a fairly small repro.  Sorry it's not smaller but it
takes a few lines of code to do the required setup.  The trickier part of
the setup is probably getting a ICMPv6 Time Exceeded error.  My particular
setup was using vtun for an IPv6 route through a dumb switch and a bogus
route on the remote vtun endpoint, but there are surely other ways to get
this error.

The app expects you to specify an IPv6 address, an IPv4 address (glibc's
inet_pton requires it be in V4MAPPED form), a port, and a nonblocking value. 
The addresses don't necessarily need to be for the same host.

Results for kernel 2.6.9 and 2.6.10-rc2 are the same, as follows:

  $ gcc -Wall -o dualconnect dualconnect.c
  $ ./dualconnect fec0::203:baff:fe88:5a15 ::ffff:192.168.168.241 22 1
  async connect to fec0::203:baff:fe88:5a15 returned No route to host
  sync  connect to ::ffff:192.168.168.241 returned Software caused connection 
abort
  async connect to ::ffff:192.168.168.241 returned Success
  $ ./dualconnect fec0::203:baff:fe88:5a15 ::ffff:192.168.168.241 22 0
  sync  connect to fec0::203:baff:fe88:5a15 returned No route to host
  sync  connect to ::ffff:192.168.168.241 returned No route to host
  sync  connect to ::ffff:192.168.168.241 returned Transport endpoint is 
already connected

In the nonblocking case (which we use, and prompted the report), the socket
appears to correct its internal state and the second IPv4 connect succeeds.

In the blocking case, the socket appears to actually connect even though it
reports an error.  I just discovered this today because I was hoping to get
a smaller repro by avoiding using select.  :-/

-- 
Don't get suckered in by the comments -- they can be terribly misleading. 
Debug only code.
        -- Dave Storer

Attachment: dualconnect.c
Description: Text Data

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>