[1731] in NetBSD-Development
Re: netbsd talk/telnet/netscape bugs
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jul 27 09:32:28 1998
To: Jamie Morris <jemorris@MIT.EDU>
Cc: netbsd-dev@MIT.EDU, sipb-athena-bugs@MIT.EDU
In-Reply-To: Your message of "Sun, 26 Jul 1998 20:47:47 EDT."
<199807270047.UAA01568@snorklewacker.mit.edu>
Date: Mon, 27 Jul 1998 09:31:57 EDT
From: Greg Hudson <ghudson@MIT.EDU>
> On snorklewacker, talk thinks I'm root --- talk requests I make show
> up as "connected requested by root@snork" and "talk root@snork"
> correctly completes the connection.
Yeah, I see the problem; we're not calling setlogin() from xlogin, so
getlogin() still returns "root" (you can run "logname" to see this
behavior). Should be easy to fix. SIPB-Athena had a fix for this,
which we missed going to source-sipb.
> Also, telnetting to the pop daemon on lantel.com fails, possibly by
> insisting on an encrypted connection.
It works if you wait long enough. The delay seems to come from
reverse-resolving lantel.com's IP address (208.225.154.129). On other
platforms, the reverse-resolve fails much faster, because only the
local named is listed in /etc/resolv.conf. (The local named on snork
and xcb both return a response with no answers very quickly for that
query; strawb and w20ns time out). /usr/bin/telnet succeeds
immediately because it does no reverse-resolve.
So, this isn't really a bug in the sipb-athena software, although it
is a configuration difference which caused you to notice some lossage
more acutely. The operational lossages here are:
* ns1.semaphore.net (as well as ns2.semaphore.net) is
responding with no answers (and not authoritative) for a ptr
query of 208.225.154.129, even though it's the authoritative
server for that domain. This isn't supposed to happen.
* The named on the MIT name servers doesn't appear to deal
very well with that case (it never responds to a recursive
query for that record, even though it got a reply from the
authoritative server), whereas the more modern named on
Athena workstations deals better.
> Also, netscape doesn't want to download mail correctly
Dunno about this one. ktrace could have helped, maybe, but it would
require some amount of talent to sift through the giant output file
it would have generated.