From: hedrick@athos.rutgers.edu (Charles Hedrick) Subject: Re: SLIP and X386 Date: 9 Sep 1992 02:24:56 GMT
rick@ee.uwm.edu (Rick Miller) writes:
>Like I said, ka9q was *made* to use a serial line. However, it doesn't
>provide connections for other applications. ka9q is *not* a service.
>It's an application which *mimics* the performance of telnet and ftp
>(which use the TCP/IP service), but does all the protocol itself.
>If you "telnet using ka9q", you're really "ka9q'ing in telnet mode".
>Get it? The 'real' telnet program (which makes TCP/IP-related system-
>calls to the kernel) wasn't even used.
Telnet is a protocol, like IP or TCP. Any program that implements the
protocol is a "real" telnet program. KA9Q implements it, so it's a
real telnet program. (In fact, it handles several telnet options more
cleanly than a stock Sun. When used with a current telnet server on
the other end, the telnet implmentation in Linux KA9Q will allow ^S
and ^Q to take effect immediately, and ^C or ^O will stop output
immediately. There is also an easy way to send the telnet special
characters. None of these things is true with the normal SunOS
telnet.) It is different than what you're used to on the Sun, because
telnet, ftp, and various other things are done in as a single program,
together with the basic IP and TCP processing, rather than as separate
utilities. This does have its limitations (e.g. not letting more than
one user use IP over a given serial line), but there's nothing unreal
about it.
The architecture of KA9Q actually does allow it to be used as a
server. I've seen a version that would support separate application
programs such as telnet and FTP. (Indeed someone claimed to have
patches for the Linux KA9Q to do this, but didn't actually send them
to me.) I envisioned KA9Q's use on Linux as temporary, until a kernel
implementation could be done. So I didn't port the general server
support. However I have put X server support in.
>The same way, 'xhost' needs kernel TCP/IP. It cannot use the ka9q package,
>because ka9q is suited only to serving a single USER, not other processes.
I'm not sure how technically you mean xhost. If you mean the ability
to talk to X from another host, this will work. Do "start x" in KA9Q.
If you mean the xhost program, xhost is a utility that lets you limit
what hosts X will talk to. I haven't put that into KA9Q yet, because
I wasn't sure it would be worth the time. Since several people seem
to find X support in KA9Q at least marginally useful, I'll probably do
it. However xhost really is a terrible way to do your X security.
.Xauthority is a better approach. I haven't tried it under Linux, but
if the server was built with it, I see no reason why it wouldn't work
through KA9Q. (You'd need to build a copy of xauth, of course, and
then FTP your .Xauthority file to the other end before opening your
first X connection.)