X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Message-ID: <4BA03ADF.8060805@cwilson.fastmail.fm> Date: Tue, 16 Mar 2010 22:13:51 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: IPv6 help (Re: inetutils, r* commands) 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> In-Reply-To: <20100316150227.GY6505@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 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