X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 17 Mar 2010 12:53:45 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: IPv6 help (Re: inetutils, r* commands) Message-ID: <20100317115345.GG6505@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4B9EEF35 DOT 9000701 AT cwilson DOT fastmail DOT fm> <20100316113210 DOT GW6505 AT calimero DOT vinschen DOT de> <4B9F8D32 DOT 9060201 AT cwilson DOT fastmail DOT fm> <20100316150227 DOT GY6505 AT calimero DOT vinschen DOT de> <4BA03ADF DOT 8060805 AT cwilson DOT fastmail DOT fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA03ADF.8060805@cwilson.fastmail.fm> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mar 16 22:13, Charles Wilson wrote: > On 3/16/2010 11:02 AM, Corinna Vinschen wrote: > > But, here's the problem. I don't know the > > mechanisms behind V4inV6, so we are (or better: I am) moving on very thin > > ice. > > Well, I ran wireshark on the vista box, and captured the negotiation: > [...] > So, if rlogind is seeing an IPv6 (or v4-in-v6) packet on an AF_INET6 > socket, it's because windows or cygwin put it there. It didn't get > "wrapped" or "translated" by my network. Wireshark sniffs right at the > driver level AFAIK... > [...] > >> Well, I didn't think I had much choice. inetd has two listeners; but the > >> incoming connection -- from the linux box -- is being routed via > >> IPv4-in-IPv6, since the incoming packet addr says "hi, I'm > >> ::ffff::192.168.1.6". A feature of the Windows IPv6 stack? But that's quite weird, considering that per MSDN the IPV6_V6ONLY socket option is set by default on AF_INET6 sockets. Cygwin does not change that in any way. > And now it turns out that was actually a lie. The packet itself is IPv4 > on the wire (actually, "in the air"). So, why is rlogind receiving it on > an AF_INET6 socket? Erm... good question. > >> Now, on the loopback connection (obv. on the Vista computer), the > >> incoming client packet says "hi, I'm ::ffff::127.0.0.1": > > > > More hmm. But that actually means it's using an AF_INET6 socket for an > > IPv4 addresses. If the target is V4 anyway, why? V4 routing through a > > V6-only network is job of the routers. > > Well, I can't wireshark the loopback interface, unfortunately. So, we'd > just be guessing here. (Well, I *could* -- but the results won't really > be reliable: http://wiki.wireshark.org/CaptureSetup/Loopback ) I tested this a bit, see the test application attached to this mail. getaddrinfo does not return loopback addresses if you refer to the name of the local machine. It does return loopback addresses only if you refer explicitely to loopback names from /etc/hosts as, for instance, "loopback". And in that case, it *only* returns V4inV6 addresses if the ai_flags member of the hints parameter contains AI_ALL | AI_V4MAPPED. On Linux, it's even worse. The results of getaddrinfo are more or less consistent between Cygwin/Windows and Linux, except for a difference in handling an unspecified ai_socktype. However, the Linux getaddrinfo implementation does nt at all return a V4inV6 address for the machine it's running on, if the AI_ALL | AI_V4MAPPED flags are set. That's independent of using the machines DNS name or "loopback". Only the Windows getaddrinfo returns V4inV6 addresses for itself in both cases, *iff* AI_ALL | AI_V4MAPPED are specified. > >>> I don't know. I don't think so. It doesn't sound right to fake a > >>> V4inV6 loopback entry. > >> > >> Ooookay. Then you can never perform a match on V4inV6 See above. > Well, a little snooping and it appears that my two IPv6-capable boxes > are all auto-configuring in the fe80::/64 subnet. So, they *ought* to be > able to see each other. However...from the linux box: > > $ ssh -6 vista > ssh: Could not resolve hostname vista: No address associated with hostname No, these link-local addresses don't work for me either, not even between two Linux boxes. Even ping6 refuses to accept these addresses: $ ping6 fe80::20c:29ff:fe9b:bca2 connect: Invalid argument I don't know why. Maybe some IPv6 guru can tell us. > However, it appears, based on the wireshark snooping, that on the wire > (or in the air!) I am NOT using V4inV6. That fact that it appears to > rlogind in an AF_INET6 socket SEEMS to be an artifact of something in > Vista or cygwin. Any ideas? You could try if setsockopt (IPV6_V6ONLY) works. Other than that, I have no idea. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple