Mail Archives: cygwin/2010/03/16/21:14:28
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
- Raw text -