X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Message-ID: <4B9F8D32.9060201@cwilson.fastmail.fm> Date: Tue, 16 Mar 2010 09:52:50 -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> In-Reply-To: <20100316113210.GW6505@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 7:32 AM, Corinna Vinschen wrote: > On Mar 15 22:38, Charles Wilson wrote: >> (*) It seems that you now need to have an identd server running on the >> *client* box, or r* authentication takes 30 seconds or so. We don't >> currrently have one of these ported; I'll try to do that at some point >> unless someone beats me to it. I've been using the following (closed >> source, free-as-in-beer) version that seems to be well-regarded: >> 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. >> 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 "server" machine. It's the rlogind daemon that is calling getaddrinfo to determine the IP address of the client-by-name (after having obtained the client's name via getnameinfo). Anyway, the server (cygwin) machine is running Vista, so that's IPv6 capable. And the client machine is either cygwin (or, in the first case, a recent linux). The linux box has /proc/net/if_inet6 lsmod |grep -w 'ipv6' show that ipv6 is loaded 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? > In that case, why don't > you get AF_INET entries? Does the server only have a AF_INET6 listener? Err...no, it has both. The actual server, on my cygwin machine, is inetd from inetutils. Unlike the other inetutils progs, it appears to have had some IPv6-related work: netstat -a TCP 0.0.0.0:512 mymachine:0 LISTENING TCP 0.0.0.0:513 mymachine:0 LISTENING TCP 0.0.0.0:514 mymachine:0 LISTENING TCP [::]:512 mymachine:0 LISTENING TCP [::]:513 mymachine:0 LISTENING TCP [::]:514 mymachine:0 LISTENING > Usually you would create two listeners, one AF_INET and one AF_INET6. > That's especially important on systems which don't support V4inV6, like > Windows XP and 2K3. 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". Now, on the loopback connection (obv. on the Vista computer), the incoming client packet says "hi, I'm ::ffff::127.0.0.1": >> mymachine rlogind: PID 5960: doit: hostok=0 >> mymachine rlogind: PID 5960: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.199.1) >> mymachine rlogind: PID 5960: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.154.1) >> mymachine rlogind: PID 5960: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.1.3) >> mymachine rlogind: PID 5960: doit: hostok=0 >> >> >> (hostok=0 means "no match/reject connection). >> >> Notice that getaddrinfo returns three different networks. Two of these >> are inactive (.199.1 and .154.1). 192.168.1.3 is mymachine's "real" IP >> addr. But 127.0.0.1 is /not/ included in the list...so it can't be matched. >> >> /etc/hosts has: >> 127.0.0.1 localhost >> ::1 localhost > > 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: rlogind: PID 7968: connect from ::ffff:127.0.0.1 (::ffff:127.0.0.1) rlogind: PID 7968: doit: hostok=0 rlogind: PID 7968: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.199.1) rlogind: PID 7968: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.154.1) rlogind: PID 7968: soaddr_eq_ip: (::ffff:127.0.0.1,192.168.1.3) rlogind: PID 7968: doit: hostok=0 >> ********************* >> 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...) >> Notice that only the "first" interface from the previous list -- >> assuming getaddrinfo returned its results in the same order as before -- >> is (in)validated. So, probably a bug -- or incompatibility of >> assumptions between tcp_wrappers and cygwin1.dll. I'll have to dig into >> that, later. FWIW, hosts.allow has: >> >> 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? > And for V6 you would have to enable ::1 anyway. But the first line does that. Or so I thought. 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. 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 unhacked (e.g. no openwrt) router/firewall? Many of these will be running old (2.4) kernels, without IPv6 support -- just like my old openwrt one. (Now, ssh (from linux to cygwin sshd) works fine...but that's because: sshd: all Replacing that with sshd: 192.168.1.0/255.255.255.0 still works fine, tho. So sshd is smarter than inetd. Not surprising. >> So, what's the second question? >> >> ********************* >> 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...) -- 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