This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: IPv6 help (Re: inetutils, r* commands)
On Mar 16 09:52, Charles Wilson wrote:
> On 3/16/2010 7:32 AM, Corinna Vinschen wrote:
> > On Mar 15 22:38, Charles Wilson wrote:
> >> http://rndware.info/products/windows-ident-server.html
> >
> > Or disable the ident code.
>
> Sure -- for the cygwin rshd/rlogind/rexecd. But at this point in my
> original message, I was talking about using the cygwin rsh/rlogin/rexec
> to connect to a server running somewhere else. We don't have control
> over what that server expects -- hence my surprise when contacting my
> linux rlogind: IT wanted the client machine to be running identd.
Oh, right.
> >> Well, since ALL of the values returned by getaddrinfo were IPv4, all
> >
> > Why? Is your client machine not IPv6 enabled?
>
> Wait, now we're talking about running rlogind on cygwin -- e.g. the
I know. The problem as far I saw it is that some "unknown" client
machine contacts the Cygwin rlogind server, which certainly was IPv6
enabled since otherwise you wouldn't have printed V4inV6 addresses
at all. Hence my question how you got V4inV6 addresses.
> So...everything should be OK. However, the DNS box is a hacked wrt54g
> running a fairly old version of openwrt; it may not be ipv6-compliant:
> no /proc/net/if_inet6
> ipv6 not loaded
> there doesn't even exist an ipv6 module in /lib/modules/
>
> Could that be the problem?
Hmm, maybe. I don't know your topology. You say "DNS" server, is that
also your router? If so, that could be the problem, if your machines
aren't directly connected but only via the router. Does your DNS return
V6 addresses at all? If you're calling some `rlogin -6' (I don't know
the actual option, but in ssh it's -6) it's possible that the addresses
are translated into V4inV6. 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.
> > In that case, why don't
> > you get AF_INET entries? Does the server only have a AF_INET6 listener?
>
> > In theory, if I were you, I would not bother with
> > V4inV6.
>
> 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".
Hmm, ok.
> 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.
> > If you want a V4inV6 match for localhost, you might have to add it to
> > /etc/hosts.
> >
> > ::ffff:127.0.0.1 localhost
> >
> > Did you try that?
>
> No, I didn't...but no joy:
And another hmm.
> >> *********************
> >> QUESTION #1. Should cygwin's getaddrinfo return an entry for the
> >> loopback interface?
> >> *********************
> >
> > 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
> "connection...without some adhoc code (oh, but is the incoming IP addr
> some form of 127.* in IPv4, IPv6, or V4inV6? ok, do this special thing...)
Here's a counter question. What does Linux do in the same situation?
> >> ALL : localhost 127.0.0.1/32 [::1]/128 : allow
> >> rlogind: 192.168.1.0/255.255.255.0
> >> rshd: 192.168.1.0/255.255.255.0
> >> rexecd: 192.168.1.0/255.255.255.0
> >
> > I don't think that these entries cover V4inV6. The localhost entry
> > only works for V4.
>
> Huh? the localhost entry has '[::1]/128' which should do the trick, right?
Another one I missed, sorry. It still doesn't match the V4inV6 localhost
address, though. Maybe this is a bug in tcp_wrappers, but I don't know.
> But you're right. I suppose I need to add something for my local
> network in regular IPv6 notation...if only I knew what that was. As I
> said, my local DNS server -- and DHCP server -- are IPv4 only. So
> frankly, I dunno how the various machines are figuring out what "their"
> IPv6 address is. Or what the local network mask is.
I have no v6 DHCP either. I'm maintaining my v6 addresses manually on
the clients as well as in DNS, using the fc00::/64 subnet. Since I
don't have to maintain a company network, just a few test machines, it's
ok for me.
> Could this be the core problem? OTOH, what of all those people who are
> running the DHCP server on the ISP's cable modem or DSL modem? Or an
Oh, come on, questions of moral, religion, politics, and law are off-topic
for this mailing list(*).
> >> QUESTION #2. Is there a cleaner way to do the address matching than the
> >> version that I've modified below? I basically only changed the guts of
> >> soaddr_eq_ip(); the rest is factory equipment...
> >
> > I think so. Take the last 32 bits of the V4inV6 address and do the
> > usual IPv4 address comparison.
>
> Ah, but I first have to do the all the casting, and I have to check that
> the IPv6 addr, if there is one, is IPv4...so, it's not /that/ much
> simpler. I can just avoid the inet_ntop step (I only did it that way
> because most of the other implementations I looked at did so; I figured
> they had a good reason...)
Well, a bit of work is probably always necessary to support that.
Another question is, if the original package doesn't support V4inV6
correctly, why bother?
Corinna
(*) Just kidding.
--
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