grn@stl.stc.co.uk (10/20/88)
Is there a public domain specification of the Berkeley networking
utilities such as rlogin?
The type of question that I would expect to be able to answer given a
specification is the use made out-of-band data in rlogin for example.
A second and related question is why does the SunOS 4.0 implementation
of rlogin and rsh reject connections with client port numbers in the
range 0-512? My desire for specification of the interoperability
requirements of these networking utilities was partly prompted by the
failure of our local rlogin implementation to interwork with the new
Sun implementation.
Regards,
Gary Nebbett STL, London Road, Harlow, Essex CM17 9NA, UK
grn@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!grn <or> PSI%234237100122::GRNroy@phri.UUCP (Roy Smith) (10/23/88)
grn@stl.stc.co.uk () writes: > The type of question that I would expect to be able to answer given a > specification is the use made out-of-band data in rlogin for example. I've been working on-and-off for a year or so trying to get my own version of rlogin working under SunOS-3.2 and lately 3.5.2. The stumbling block has been the out-of-band data part. Basicly, rlogin uses oob to negotiate options such as "please inform me of window-size changes", but as to the details of exactly how it works, I've had to just read the source code (not a useful answer if you don't have source). I sort of think I might have most of it figured out, but not well enough that I would risk inflicting my misconceptions on other people. Perhaps I've made my job harder than it has to be by trying to get my rlogin to run as a suntools application. I use the notifier to tell me when oob data is available, but I don't think it works properly. Sometimes, my oob routine gets called by the notifier (which supposedly means there is oob data waiting to be read) but when I try to read it, nothing is there (i.e. select says there is nothing pending, recv returns 0, ioctl says I'm not at the mark, etc). -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) (10/24/88)
> Is there a public domain specification of the Berkeley networking > utilities such as rlogin? Unfortunately, no; the source code itself, however, while not public domain, is freely redistributable. This includes inetd, ping, rcp, rdist, rexecd, rlogin, rmt, route, rsh, rwho, rwhod, and talk among other things. Keith Bostic
root@sbcs.sunysb.edu (root) (10/24/88)
In article <8810232211.AA18006@okeeffe.Berkeley.EDU>, bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) writes: > > Is there a public domain specification of the Berkeley networking > > utilities such as rlogin? > > Unfortunately, no; the source code itself, however, while not public > domain, is freely redistributable. This includes inetd, ping, rcp, > rdist, rexecd, rlogin, rmt, route, rsh, rwho, rwhod, and talk among > other things. Have these things been published to a place where we can FTP them? If not they are not public domain. What of the library routines they rely on? Can they be FTP'ed? > > Keith Bostic Rick Spanbauer SUNY/Stony Brook
henry@utzoo.uucp (Henry Spencer) (10/25/88)
In article <845@acer.stl.stc.co.uk> grn@stl.stc.co.uk () writes: >Is there a public domain specification of the Berkeley networking >utilities such as rlogin? <Chortle> Berkeley? Document their protocols? It is to laugh! (Or maybe to cry...) -- The dream *IS* alive... | Henry Spencer at U of Toronto Zoology but not at NASA. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dupuy@douglass.columbia.edu (Alexander Dupuy) (10/25/88)
Here's an old message which may shed light on your problems:
Article 1996 of comp.protocols.tcp-ip:
Path: columbia!rutgers!lll-lcc!lll-tis!ptsfa!rtech!daveb
From: daveb@rtech.UUCP (Dave Brower)
Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip
Subject: OOB problems, wisdom anyone?
Message-ID: <1482@rtech.UUCP>
Date: 18 Dec 87 19:58:03 GMT
Reply-To: daveb@rtech.UUCP (Dave Brower)
Organization: Relational Technology Inc, Alameda CA
Lines: 44
Xref: columbia comp.unix.wizards:6073 comp.protocols.tcp-ip:1996
Some people here have been trying to use the OOB mechanism to send
"expedited data" between processes. No one here is all that familiar
with using it, and they have run into some problems that make them want
to give up and turn to something else.
I'd appreciate hearing general thoughts about using the BSD oob
mechanism for IPC, and specific comments on the problems they report
below. I will forward responses to the interested parties.
Thanks!
-dB
------- forwarded message describing OOB headaches.
1. "Leapfrogging:" The fatal aspect of OOB data is that when two
socket sends for OOB data are issued in sequence before the first has
been read, the second send passes the first and is read out of
sequence by the recipient. This is a gross violation of the stream
socket abstraction and makes the mechanism fundamentally unusable
except in the simplest and most restricted cases, not the situation
here.
2. OOB receive loop: When an application has been notified of the
availability of OOB data and issues a receive for it, a subsequent
receive for normal data must be issued to "clear" the OOB notification
mechanism. If instead a select requesting notification of OOB data is
issued without an intervening receive for normal data, the caller is
immediately notified of the availability of OOB data: the same data
just received. This is at best a form of bizarre and undocumented
behavior; at worst a serious bug.
3. The integer-character problem: The IOCTL system call to determine
whether one has reached the OOB data in the stream is documented to
return a character. Several coding examples support this. In fact,
an integer is returned. It was necessary, after considerable grief,
to go to kernel source code to find that in fact an integer is
returned. It is not known how many similar major documentation errors
exist. Each could cause major delays, with time spent in fruitless
debugging.
--
"If it was easy, we'd hire someone cheaper than you to do it."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucp
--
inet: dupuy@columbia.edu
uucp: ...!rutgers!columbia!dupuychet@pirate.CWRU.EDU (Chet Ramey) (10/26/88)
In article <1988Oct24.200243.19459@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <845@acer.stl.stc.co.uk> grn@stl.stc.co.uk () writes: >>Is there a public domain specification of the Berkeley networking >>utilities such as rlogin? > ><Chortle> Berkeley? Document their protocols? It is to laugh! (Or >maybe to cry...) Mike Karels said last year that he was avoiding making the `r-series' protocol specs public (i.e. documenting them) because he was lobbying some people to add extensions to Telnet to do the stuff that rlogin does (e.g. pass the environment). He said he hoped that if that stuff got into Telnet, rlogin and friends could just fade away quietly without proliferating. (Christ, Henry, don't you ever have anything nice to say about Berkeley? Even once? (Henry? Say something nice about Berkeley? It is to laugh! :-)) Chet Ramey Chet Ramey chet@cwjcc.CWRU.EDU Network Management Group chet@alpha.CES.CWRU.EDU Andrew R. Jennings Computing Center chet@pirate.CWRU.EDU Case Western Reserve University
hrp@snoid.CRAY.COM (Hal Peterson) (10/26/88)
According to Mike Karels, there are no plans to write specifications for the protocols used by the r-commands because they were originally hacks to try out TCP and should die a natural death. If they were documented, then people would be implementing them, they would proliferate, and there would be no getting rid of them. The party line is that 4.3 telnet is better anyway, so we should all be using that. [The information is from a the question and answer session at a tutorial Mike Karels gave at the Monterey TCP/IP conference last year.] -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.cray.com@uc.msc.umn.edu bungia!cray!hrp (612) 681-3145
phil@BRL.MIL (Phil Dykstra) (10/26/88)
> If they were documented, then people would be implementing them, they > would proliferate, and there would be no getting rid of them. The party > line is that 4.3 telnet is better anyway, so we should all be using that. Surely you jest! Maybe once telnet can: (1) log you in without requiring a password in a file, (2) handle remote window size changes, (3) handle OOB data for (e.g.) SIGINT output flushing, and (4) have every machine handle raw octet data correctly, then I'll believe you. For RLOGIN. Try to do RCP and RSH with Telnet .... As for proliferation, in this building alone I've got Suns, SGIs, Vaxes, Alliants, Goulds, and even a Cray that implements it. Its too late for them to die out. - Phil
craig@SH.CS.NET (Craig Partridge) (10/26/88)
> Maybe once telnet can: .... (2) handle remote window size changes
See RFC 1073
Craigzeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/26/88)
In article <211@cwjcc.CWRU.Edu> chet@pirate.UUCP (Chet Ramey) writes: >some people to add extensions to Telnet to do the stuff that rlogin does >(e.g. pass the environment). He said he hoped that if that stuff got Don't forget the transparency. Full 8 bit file transfers (like uucp 'g') don't work over telnet). -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
braden@VENERA.ISI.EDU (10/27/88)
Surely you jest! Maybe once telnet can: (1) log you in without requiring a password in a file, (2) handle remote window size changes, (3) handle OOB data for (e.g.) SIGINT output flushing, and (4) have every machine handle raw octet data correctly, then I'll believe you. Phil, I believe that a properly implemented Telnet can handle all except (1) (note that RFC-1073 just got around to fixing (2)). Not everyone agrees that (1) is a good idea, although we obviously need a secure method to accomplish the same thing. It appears to me that the purported advantages of rlogin are due to poor Telnet implementations; do you disagree? Bob Braden
barmar@think.COM (Barry Margolin) (10/27/88)
In article <8810260021.aa23976@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes: >Surely you jest! Maybe once telnet can: (1) log you in without requiring >a password in a file, (2) handle remote window size changes, (3) handle >OOB data for (e.g.) SIGINT output flushing, and (4) have every machine >handle raw octet data correctly, then I'll believe you. There's no reason why TELNET couldn't do all those things. The TELNET option mechanism provides nearly infinite expansion capability. (1) A TELNET server that supports such a feature could send IAC DO SEND-USERNAME (a new option I just made up) before sending the "login:" prompt. If the client supports this it will respond with IAC WILL SEND-USERNAME and then uses the subnegotiation mechanism to send the name. The server would then bypass the normal login prompt and log the user in, subject to access checks like those rlogin does. (2) There are already standardized TELNET options for transmitting line length and screen height. Either these could be used or a new window-size negotiation could be defined. (3) TELNET already has this: IAC AO (Abort Output). There is also an IAC code for sending an interrupt. Other OOB data could be implemented using options. (4) Again, this just needs a new option. Actually, many implementations interpret the TRANSMIT-BINARY negotiation as specifying this. This could be made official, or a new option could be defined. Yes, these things would require changes to TELNET implementations. However, the effort to modify a TELNET implementation to support these should be less than the effort to write an RLOGIN implementation from scratch. Of course, if you already have an RLOGIN implementation you aren't going to be interested in modifying TELNET; even if you don't, it's probably easier to port one than to extend TELNET. The problem isn't that TELNET can't do what RLOGIN does, it's that nobody bothered to define the necessary TELNET enhancements before RLOGIN proliferated. I think it's too late, and anyone who thinks that RLOGIN can be phased out is dreaming. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
lear@NET.BIO.NET (Eliot Lear) (10/27/88)
Telnet certainly can handle binary transfers. It is quite possible that the current implementations do not do it correctly, but the specification certainly provides for it. See RFC 856. -- Eliot Lear [lear@net.bio.net]
hedrick@athos.rutgers.edu (Charles Hedrick) (10/27/88)
>Don't forget the transparency. Full 8 bit file transfers (like uucp 'g') >don't work over telnet). We do UUCP and xmodem over telnet all the time. Rutgers.edu is a major UUCP hub. All of its dialup UUCP transactions are done through TCP/IP terminal servers. (For reasons of efficiency on the host, we are experimenting with having the terminal server go through a raw TCP connection directly into uucpd. However most connections still go through telnet.) For complete transparency, we require the user to type "term download" on the terminal server. This disables the sequence that would otherwise get you back into command mode on the terminal server (like ~ in rlogin), and makes a set of protocol choices that provide an 8 bit transparent path with most of our server telnet implementations. You could do this by using telnet binary mode. However since binary mode doesn't always seem to work on Unix telnet, we do it in normal mode simply by making sure that we choose an end of line representation that is consistent with the one used by the Unix server telnet.
mckee@MITRE.ARPA (H. Craig McKee) (10/27/88)
Barry Margolin (Thinking Machines Corp) writes: >The problem isn't that TELNET can't do what RLOGIN does, it's that >nobody bothered to define the necessary TELNET enhancements before >RLOGIN proliferated. I think it's too late, and anyone who thinks >that RLOGIN can be phased out is dreaming. As if TELNET and RLOGIN weren't enough, there are folks busily developing a new standard for the ISO Virtual Terminal Protocol.
guy@auspex.UUCP (Guy Harris) (10/28/88)
>According to Mike Karels, there are no plans to write specifications >for the protocols used by the r-commands because they were originally >hacks to try out TCP and should die a natural death. If they were >documented, then people would be implementing them, they would >proliferate, and there would be no getting rid of them. Just like Sun and ND (yes, that's why it was never published).... >The party line is that 4.3 telnet is better anyway, so we should all be >using that. If "4.3" means "4.3BSD", rather than "4.3-tahoe", this isn't quite true; the 4.3BSD "telnet" doesn't pass the screen size over the wire, while the 4.3BSD "rlogin" does so every time it changes. I don't think I found any TELNET option to do that when I looked for one, but this doesn't mean it isn't there - is there such an option? Has one been proposed?
guy@auspex.UUCP (Guy Harris) (10/28/88)
>Don't forget the transparency. Full 8 bit file transfers (like uucp 'g') >don't work over telnet). Do people run UUCP over "rlogin"? If so, and the UUCP on both ends supports it, they should consider running UUCP with the 't' protocol directly over TCP instead. TELNET does have a binary mode; I don't know if this is the Right Thing here or not. It would be nice to have it support character sets wider than 7 bits - in fact, it would be nice to have it support character sets wider than 8 bits....
VAF@SCORE.STANFORD.EDU (Vince Fuller) (10/28/88)
(1) A TELNET server that supports such a feature could send IAC DO
SEND-USERNAME (a new option I just made up) before sending the
"login:" prompt. If the client supports this it will respond with IAC
WILL SEND-USERNAME and then uses the subnegotiation mechanism to send
the name. The server would then bypass the normal login prompt and
log the user in, subject to access checks like those rlogin does.
Actually, I think this capability is already defined in TELNET. Take a look at
RFC927 for the details.
Vince Fuller, Stanford Networking
-------henry@utzoo.uucp (Henry Spencer) (10/29/88)
In article <211@cwjcc.CWRU.Edu> chet@pirate.UUCP (Chet Ramey) writes: >Mike Karels... said he hoped that if that stuff got >into Telnet, rlogin and friends could just fade away quietly without >proliferating. I'm afraid he's being wildly optimistic. The time to kill rlogin and friends was five minutes before the 4.2 tapes started shipping. It's far too late now. >(Christ, Henry, don't you ever have anything nice to say about Berkeley? >Even once? (Henry? Say something nice about Berkeley? It is to laugh! :-)) You wound me, sir. I said something nice about Berkeley just last year. :-) Actually, they've done a lot of good stuff, and the world is better off with them than without them, but the world (especially the networking world) would be a nicer place if some of the effort that went into (e.g.) 1986's wonderful new ideas had gone into rethinking and cleaning up (e.g.) 1985's. -- The dream *IS* alive... | Henry Spencer at U of Toronto Zoology but not at NASA. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
barmar@think.COM (Barry Margolin) (10/29/88)
In article <12441844876.13.VAF@Score.Stanford.EDU> VAF@SCORE.STANFORD.EDU (Vince Fuller) writes: > > (1) A TELNET server that supports such a feature could send IAC DO > SEND-USERNAME (a new option I just made up) before sending the >Actually, I think this capability is already defined in TELNET. Take a look at >RFC927 for the details. So it is. I guess great minds think alike. One problem with the protocol in RFC927, though, is that the userid that is transmitted is interpreted as a 32-bit binary number. Not all OSes have numeric userids, though. Multics and Genera both use character string user names, and don't translate them into numbers internally. Why was the protocol defined in such a restrictive manner? Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
guy@auspex.UUCP (Guy Harris) (10/29/88)
> (1) A TELNET server that supports such a feature could send IAC DO > SEND-USERNAME (a new option I just made up) before sending the > "login:" prompt. .... > >Actually, I think this capability is already defined in TELNET. Take a look at >RFC927 for the details. Not quite. RFC927 specifies that the hosts exchange a 32-bit "UUID", not a name; "rlogin"s auto-login feature permits the same user name to have different UNIX numeric user IDs.