This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IPv6 help (Re: inetutils, r* commands)


On 3/16/2010 11:02 AM, Corinna Vinschen wrote:
> On Mar 16 09:52, Charles Wilson wrote:
>> 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. 

  cable-modem
       |
    router (NAT; all other services like dhcp disabled)
     |  |
wired|  +-- wireless -- my Vista box (rlogind server)
     |  |
     |  +-- wireless -- my XP box (been off for months)
     |
     +----- DNS, DHCP, NTP server
     |      WRTSL54GS running fairly old openwrt
     |
     +----- linux box

All boxes behind the router are on the same /24 IPv4 subnet.  There are
a whole bunch of other toys connected to the network at various times,
but they aren't important for our purposes.

I suppose it's possible that the router is doing some odd v4-v6
translation when bridging the wired and wireless networks, but -- as it
turns out -- that is not the case.  See below.

> 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?

No.  The openwrt box is running an *old* version of dnsmasq, which
handles both dns and dhcp.  However, that version only knows IPv4;
besides, the kernel is 2.4.x and IPv6 wasn't really supported in-tree
until 2.6.something.  Even today's version of dnsmasq only knows how to
do DNS IPv6; it still doesn't support DHCPv6 (newer openwrt releases use
wide-dhcpv6 or 'dripper'(?) to do that).

> 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. 

Nope. Just plain old 'rlogin'.

> 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:

   from IP      to IP
1  linux (.6)   vista (.3)	TCP	1023 > login [SYN]
2  vista (.3)   linux (.6)	TCP	login > 1023 [SYN, ACK]
3  linux (.6)   vista (.3)	TCP	1023 > login [ACK]
4  linux (.6)   vista (.3)	Rlogin	Start Handshake

Each of these packets, if you look at the decoding, are IPv4, not IPv6
or v4-in-v6:

Internet Protocol
    Src: linux x.x.x.6 (x.x.x.6),
    Dst: vista x.x.x.3 (x.x.x.3)
	Version: 4
	Header length: 20

But, what did the cygwin rlogind report to syslog?

rlogind: PID 7136: connect from linux (::ffff:192.168.1.6)
rlogind: PID 7136: doit: hostok=0
rlogind: PID 7136: soaddr_eq_ip: (::ffff:192.168.1.6,192.168.1.6)
rlogind: PID 7136: doit: hostok=1

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".
> 
> Hmm, ok.

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?

>> 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 )

>>> 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?

Connections from vista box go out as IPv4:
   from IP      to IP
1. vista (.3)   linux (.6)	TCP	981 > login [ACK]
2. linux (.6)   vista (.3)	Rlogin	Start Handshake

>>>>  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.

tcp_wrappers treats localhost as a special case in its PARANOID
(ip->name->ip) checking, which is analogous to what rlogind is doing
here. In tcp_wrapper's socket.c (host_info):

if (!err) {
 /* we are now sure that this is non-numeric */

 /*
  * Verify that the address is a member of the address list returned
  * by gethostbyname(hostname).
  *
  * Verify also that gethostbyaddr() and gethostbyname() return the same
  * hostname, or rshd and rlogind may still end up being spoofed.
  *
  * On some sites, gethostbyname("localhost") returns "localhost.domain".
  * This is a DNS artefact. We treat it as a special case. When we
  * can't believe the address list from gethostbyname("localhost")
  * we're in big trouble anyway.
  */

  memset(&hints, 0, sizeof(hints));
  hints.ai_family = sin->sa_family;
  hints.ai_socktype = SOCK_STREAM;
  hints.ai_flags = AI_PASSIVE | AI_CANONNAME;
  if (getaddrinfo(host->name, NULL, &hints, &res0) != 0) {
    /*
     * Unable to verify that the host name matches the address. This
     * may be a transient problem or a botched name server setup.
     */
     tcpd_warn("can't verify hostname: getaddrinfo(%s, %s) failed",
               host->name,
              (sin->sa_family == AF_INET) ? "AF_INET" : "AF_INET6");

  } else if ((res0->ai_canonname == NULL
             || STR_NE(host->name, res0->ai_canonname))
             && STR_NE(host->name, "localhost")) {
    /*
     * The gethostbyaddr() and gethostbyname() calls did not return
     * the same hostname. This could be a nameserver configuration
     * problem. It could also be that someone is trying to spoof us.
     */

    tcpd_warn("host name/name mismatch: %s != %.*s",
              host->name, STRING_LENGTH,
              (res0->ai_canonname == NULL) ? "" : res0->ai_canonname);
  } else {
  ...

I suppose I could put a similar short circuit in there, too...but that's
not the problem I'm having.  Inside rlogind's network.c (find_hostname),
we have:

        error = getnameinfo(fromp, fromlen,
                hname_buf, sizeof(hname_buf), portname, NI_MAXSERV,
                NI_NUMERICSERV);

But, with this incoming packet src addr (127.0.0.1, or ::ffff:127.0.01,
or whatever the heck it is), getnameinfo returns not 'localhost' but
rather 'mymachine' -- e.g. the name of my vista box.

At that point, we kick ask for all the IPs associated with the name
"mymachine" -- not "localhost" (or "localhost.mydomain").

(FYI, the tcp_wrappers falls into the same "trap" with localhost on my
box, which is why 'rlogin localhost' ALSO generates the following
message from tcp_wrappers, before rlogin gets to do its thing:

rlogind: PID 7316: warning: /etc/hosts.allow, line 11: host name/address
mismatch: 127.0.0.1 != mymachine

Since I have "localhost: allow" *before* "paranoid: deny", I can still
connect using 'rlogin localhost' -- or I would be able to, if rlogind
didn't complain...

>> 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.

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

OK, let's use vista's IPv6 addr
$ ssh -6 fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx
ssh: connect to host fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx port 22:
Invalid argument

Hmm. let's mistype the network:
$ ssh -6 ff80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx
ssh: connect to host ff80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx port 22:
Network is unreachable

In any case, since I have a router (*) bridging the wired (linux)
network and the wireless, so I guess I shouldn't expect this to work anyway.

(*) very old, probably doesn't grok IPv6

>> 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(*).

Yeah, well, I always did like a good fight.

>>>> 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...
> 
> 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?

Well, because if I can't get it working in my local network, I can't
very well unleash it onto the world.

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?

--
Chuck

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]