jam@RADC-LONEX.ARPA (10/24/88)
>>from grn@stl.stc.co.uk: >> >>Is there a public domain specification of the Berkeley networking >>utilities such as rlogin? > Keith Bostic: > >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. To quote my friend Schultzy: "The source code is the ultimate documentation..." This isn't exactly the clearest source code, so I will make a humble attempt to explain what goes on (also benefiting those without it): >>grn@stl.stc.co.uk: >> >>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. OOB data is used to pass four flags to the client: #define TIOCPKT_FLUSHWRITE 0x02 #define TIOCPKT_NOSTOP 0x10 #define TIOCPKT_DOSTOP 0x20 #define TIOCPKT_WINDOW 0x80 Any others are ignored. TIOCPKT_FLUSHWRITE does just that, the client flushes the terminal queues, and any data up to the OOB mark. TIOCPKT_WINDOW causes the client to signal its parent process of a window size change. TIOCPKT_NOSTOP turns disables CBREAK, enables RAW, sets t_stopc and t_startc to -1. TIOCPKT_DOSTOP reverses the effects of TIOCPKT_NOSTOP. This assumes a knowledge of the Berkeley terminal driver. The oob data is written and read as type char. >phri!roy.hyu.edu > > 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. > > (text deleted) > > 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). I would have to see the source code to make a determination about this, but it sounds like the evaluation is correct. For the benefit of others: make sure that you read in the data up to the mark and store it for later, or throw it away. It is possible that the oob data has not been sent because the process is blocked on output and the input buffer is full. >>grn@stl.stc.co.uk: >> >>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. Low numbers are reserved for servers. A client process shouldn't be down in this range. Rlogind and rshd reject numbers below IPPORT_RESERVED/2 (512) just for good measure. Also they expect numbers between IPPORT_RESERVED/2 and IPPORT_RESERVED to guarantee the authenticity of the client. Joel A. Mussman jam@radc-lonex.arpa, jam@etn-wlv.eaton.com
chris@GYRE.UMD.EDU (Chris Torek) (10/26/88)
Joel A. Mussman (jam@radc-lonex.arpa) notes: >OOB data is used to pass four flags to the client: > > #define TIOCPKT_FLUSHWRITE 0x02 > #define TIOCPKT_NOSTOP 0x10 > #define TIOCPKT_DOSTOP 0x20 > #define TIOCPKT_WINDOW 0x80 > >Any others are ignored. This is true, but only because the others are hard to implement in the current Berkeley system. There are three more: #define TIOCPKT_FLUSHREAD 0x01 This is intended to throw out typeahead. Only that typeahead which was present when the out of band data itself was sent should be discarded; since there is no way to tell when that was, the current rlogin client ignores this. #define TIOCPKT_STOP 0x04 /* stop output */ #define TIOCPKT_START 0x08 /* start output */ Upon receiving a STOP, the client should stop copying output, and should cause the local tty device to stop producing output, but *not* stop receiving; the client should resume output (without dicarding anything) upon receiving a START. Servers should never send both STOP and START in the same OOB data, but if it happens I suspect the proper action is to resume if currently stopped, and otherwise to do nothing. Stop and start ought to be unnecessary, but the DOSTOP/NOSTOP protocol only accomodates ^S/^Q flow control. Positive flow control (ENQ/ACK and the like) does not need STOP and START, but negative flow control using characters other than ^S/^Q will in fact generate STOP and START requests. Chris