Mail Archives: cygwin/2010/03/17/06:53:57
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
- Raw text -