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


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