home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!igor.rutgers.edu!athos.rutgers.edu!hedrick
- From: hedrick@athos.rutgers.edu (Charles Hedrick)
- Newsgroups: comp.os.linux
- Subject: Re: SLIP and X386
- Message-ID: <Sep.8.22.24.55.1992.9151@athos.rutgers.edu>
- Date: 9 Sep 92 02:24:56 GMT
- References: <55pnpxd.genie@netcom.com> <1992Sep8.151235.3292@uwm.edu>
- Organization: Rutgers Univ., New Brunswick, N.J.
- Lines: 49
-
- 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.)
-