home *** CD-ROM | disk | FTP | other *** search
/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / OSK / TELECOM / UUCP_Blars.lzh / DOC / uucp.doc < prev    next >
Text File  |  1990-06-25  |  20KB  |  498 lines
  1.                             UUCP Documentation
  2.                             ------------------
  3.  
  4. This file was received from UseNet and is presented here mostly as
  5. I got it.  Some addtitions have been made to further explain the
  6. workings of the UUCP protocol.
  7.  
  8. Mark Griffith, June 1990
  9.  
  10.  =====================================================
  11.  -- part 1
  12.  =====================================================
  13. This information came via several people, most of whom sent this
  14. exact message (probably from their news archives from before we
  15. joined the net):
  16.  
  17.         I am posting this over the network because I believe that
  18.         others are interested in knowing the protocols of UUCP.
  19.         Below is listed all the information that I have acquired
  20.         to date. This includes the initial handshaking phase, though
  21.         not the login phase. It also doesn't include information
  22.         about the data transfer protocol for non-packet networks
  23.         (the -G option left off the uucico command line). But, just
  24.         hold on - I am working on that stuff.
  25.  
  26.         For a point of information : the slave is the UUCP site being
  27.         dialed, and the master is the one doing the calling up. The
  28.         protocols listed in the handshaking and termination phase are
  29.         independent of any UUCP site : it is universal. The stuff in
  30.         the work phase depends on the specific protocol chosen. The
  31.         concepts in the work phase are independent of protocol, ie. the
  32.         sequences are the same. It is just the lower level stuff that
  33.         changes from protocol to protocol. I have access only to level
  34.         g and will document it as I begin to understand it.
  35.  
  36.         Most of the stuff you see here is gotten from the debug phase
  37.         of the current BSD UUCP system.
  38.  
  39.         I hope this is useful. Maybe this will get some of the real
  40.         'brains' in UUCP to get off their duffs and provide some real
  41.         detail. In any case, if you have any questions please feel
  42.         free to contact me. I will post any questions and answers over
  43.         the network.
  44.  
  45.  
  46.                                 Chuck Wegrzyn
  47.                                 {allegra,decvax,ihnp4}!encore!wegrzyn
  48.  
  49.                                 (617) 237-1022
  50.  
  51.  
  52.  
  53.                         UUCP Handshake Phase
  54.                         ====================
  55.  
  56. Master                                                  Slave
  57. ------                                                  -----
  58.  
  59.                                         <-----          \020Shere\0     (1)
  60.  
  61.  
  62. (2)  \020S<mastername> <switches>\0     ----->
  63.  
  64.  
  65.                                         <-----          \020RLCK\0      (3)
  66.                                                         \020RCB\0
  67.                                                         \020ROK\0
  68.                                                         \020RBADSEQ\0
  69.  
  70.                                         <-----          \020P<protos>\0 (4)
  71.  
  72.  
  73. (5) \020U<proto>\0                      ----->
  74.     \020UN\0
  75.  
  76.  
  77. (6) ...
  78.  
  79.  
  80. (0) This communication happens outside of the packet communication that
  81.         is supported. If the -G flag is sent on the uucico line, all
  82.         communications will occur without the use of the packet
  83.         simulation software. The communication at this level is just
  84.         the characters listed above.
  85.  
  86. (1) The slave sends the sequence indicated, while the master waits for
  87.         the message.
  88.  
  89. (2) The slave waits for the master to send a response message. The message
  90.         is composed of the master's name and some optional switches.
  91.         The switch field can include the following
  92.  
  93.                         -g              (set by the -G switch on the
  94.                                          master's uucico command line.
  95.                                          Indicates that communication
  96.                                          occurs over a packet switch net.)
  97.                         -xN             (set by the -x switch on the
  98.                                          master's uucico command line.
  99.                                          The number N is the debug level
  100.                                          desired.)
  101.                         -QM             (M is really a sequence number
  102.                                          for the communication.)
  103.  
  104.         Each switch is separated from the others by a 'blank' character.
  105.  
  106. (3) The slave will send one of the many responses. The meanings appear to
  107.         be :
  108.  
  109.         RLCK
  110.  
  111.                 This message implies that a 'lock' failure occurred:
  112.                 a file called LCK..mastername couldn't be created since
  113.                 one already exists. This seems to imply that the master
  114.                 is already in communication with the slave.
  115.  
  116.         RCB
  117.  
  118.                 This message will be sent out if the slave requires a
  119.                 call back to the master - the slave will not accept a
  120.                 call from the master but will call the master instead.
  121.  
  122.         ROK
  123.  
  124.                 This message will be returned if the sequence number that
  125.                 was sent in the message, attached to the -Q switch, from
  126.                 the master is the same as that computed on the slave.
  127.  
  128.         RBADSEQ
  129.  
  130.                 Happens if the sequence numbers do not match.
  131.  
  132.         (Notes on the sequence number - if a machine does not keep
  133.          sequence numbers, the value is set to 0. If no -Q switch
  134.          is given in the master's line, the sequence number is
  135.          defaulted to 0.
  136.  
  137.          The sequence file, SQFILE, has the format
  138.  
  139.                 <remotename> <number> <month>/<day>-<hour>:<min>
  140.  
  141.          where <remotename> is the name of a master and <number>
  142.          is the previous sequence number. If the <number> field
  143.          is not present, or if it is greater than 9998, it is
  144.          set to 0. The <number> field is an ascii representation
  145.          of the number. The stuff after the <number> is the time
  146.          the sequence number was last changed, this information
  147.          doesn't seem important.)
  148.  
  149. (4) The slave sends a message that identifies all the protocols that
  150.         it supports. It seems that BSD supports 'g' as the normal case.
  151.         Some sites, such as Allegra, support 'e' and 'g', and a few
  152.         sites support 'f' as well. I have no information about these
  153.         protocols. The exact message sent might look like
  154.  
  155.                 \020Pefg\0
  156.  
  157.         where efg indicates that this slave supports the e,f and g
  158.         protocols.
  159.  
  160. (5) The slave waits for a response from the master with the chosen
  161.         protocol. If the master has a protocol that is in common the
  162.         master will send the message
  163.  
  164.                 \020U<proto>\0
  165.  
  166.         where <proto> is the protocol (letter) chosen. If no protocol
  167.         is in common, the master will send the message
  168.  
  169.                 \020UN\0
  170.  
  171. (6) At this point both the slave and master agree to use the designated
  172.         protocol. The first thing that now happens is that the master
  173.         checks for work.
  174.  
  175. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  176.  
  177.                         UUCP Work Phase
  178.                         ===============
  179.  
  180.  
  181. Master                                                  Slave
  182. ------                                                  -----
  183.  
  184. (a) Master has UUCP Work
  185.  
  186.         (1) X file1 file2       ----->
  187.  
  188.                                         <-----          XN              (2)
  189.                                                         XY
  190.  
  191.         When the master wants the slave to do a 'uux' command
  192.         it sends the X message. If the slave can't or won't
  193.         do it, the slave will send an XN message. Otherwise
  194.         it will send an XY message.
  195.  
  196. (b) Master wants to send a file
  197.  
  198.         (1) S file1 file2 user options  ----->
  199.  
  200.                                         <-----          SN2             (2)
  201.                                                         SN4
  202.                                                         SY
  203.  
  204.                         <---- <data exchanged>---->                     (3)
  205.  
  206.  
  207.                                         <-----          CY              (4)
  208.                                                         CN5
  209.  
  210.         If the master wishes to send a file to the slave, it will
  211.         send a S message to the slave. If the slave can or will do
  212.         the transfer, it sends a SY message. If the slave has a
  213.         problem creating work files, it sends a SN4 message. If
  214.         the target file can't be created (because of priv's etc)
  215.         it sends a SN2 message.
  216.  
  217.         The file1 argument is the source file, and file2 is the
  218.         (almost) target filename. If file2 is a directory, then
  219.         the target filename is composed of file2 concatenated
  220.         with the "last" part of the file1 argument. Note, if the
  221.         file2 argument begins with X, the request is targeted to
  222.         UUX and not the normal send.
  223.  
  224.         The user argument indicates who, if anyone, is to be notified
  225.         if the file has been copied. This user must be on the slave
  226.         system.
  227.  
  228.         I am not sure what the options argument does.
  229.  
  230.         After the data has been exchanged the slave will send one of
  231.         two messages to the master. A CY message indicates that every-
  232.         thing is ok. The message CN5 indicates that the slave had
  233.         some problem moving the file to it's permanent location. This
  234.         is not the same as a problem during the exchange of data : this
  235.         causes the slave to terminate operation.
  236.  
  237. (c) Master wishes to receive a file.
  238.  
  239.         (1) R file1 file2 user  ----->
  240.  
  241.                                                 <-----  RN2             (2)
  242.                                                         RY mode
  243.  
  244.         (3)             <---- <data exchanged> ---->
  245.  
  246.         (4)     CY              ----->
  247.                 CN5
  248.  
  249.         If the master wishes the slave to send a file, the master sends
  250.         a R message. If the slave has the file and can send it, the
  251.         slave will respond with the RY message. If the slave can't find
  252.         the file, or won't send it the RN2 message is sent. It doesn't
  253.         appear that the 'mode' field of the RY message is used.
  254.  
  255.         The argument file1 is the file to transfer, unless it is a
  256.         directory. In this case the file to be transferred is built
  257.         of a concatenation of file1 with the "last" part of the file2
  258.         argument.
  259.  
  260.         If anything goes wrong with the data transfer, it results in
  261.         both the slave and the master terminating.
  262.  
  263.         After the data has been transferred, the master will send an
  264.         acknowledgement to the slave. If the transfer and copy to the
  265.         destination file has been successful, the master will send the
  266.         CY message. Otherwise it will send the CN5 message.
  267.  
  268. (d) Master has no work, or no more work.
  269.  
  270.         (1) H                   ----->
  271.  
  272.                                 <-----                          HY      (2)
  273.                                                                 HN
  274.  
  275.         (3) HY                  ----->
  276.  
  277.                                 <----                           HY      (4)
  278.  
  279.         (5) ...
  280.  
  281.         The transfer of control is initiated with the master sending
  282.         a H message. This message tells the slave that the master has
  283.         no work, and the slave should look for work.
  284.  
  285.         If the slave has no work it will respond with the HY message.
  286.         This will tell the master to send an HY message, and turn off
  287.         the selected protocol. When the HY message is received by the
  288.         slave, it turns off the selected protocol as well. Both the
  289.         master and slave enter the UUCP termination phase.
  290.  
  291.         If the slave does have work, it sends the HN message to the
  292.         master. At this point, the slave becomes the master. After
  293.         the master receives the HN message, it becomes the slave.
  294.         The whole sequence of sending work starts over again. Note,
  295.         the transmission of HN doesn't force the master to send any
  296.         other H messages : it waits for stuff  from the new master.
  297.  
  298.         NOTE: If something goes wrong within the packet phase such as
  299.         the slave not receiving what it expects, the slave will very
  300.         often send a series of 6 "O's" (hex 4f) to force a termination.
  301.         (MDG)
  302.  
  303.  
  304. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  305.  
  306.  
  307.                         UUCP Termination Sequence
  308.                         =========================
  309.  
  310.  Master                                                         Slave
  311.  ------                                                         -----
  312.  
  313.  (1) \020OOOOOO\0               ----->
  314.  
  315.                                 <-----                  \020OOOOOOO\0 (2)
  316.  
  317.  
  318.  
  319.         At this point all conversation has completed normally.
  320.  
  321.  
  322. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  323.  
  324.                         UUCP Data Transfers
  325.                         ===================
  326.  
  327.         After the initial handshake the systems send messages in one
  328.         of two styles : packet and not packet. A Packet protocol is
  329.         just raw data transfers : there is no protocol or acknowledgements;
  330.         this appears to assume that the lower level is a packet network
  331.         of some type. If the style is not Packet, then extra work is
  332.         done. I am still working on this stuff.
  333.  
  334.  =====================================================
  335.  -- part 2
  336.  =====================================================
  337.  ** summary of UUCP packets **
  338. (this is much like part 1, but shortened and compared against a
  339. live UUCP ~uucp_adm/uucico)
  340.  
  341. note that all transmissions end with a null, not shown here
  342.  
  343.  
  344. (master)                (slave)
  345.  
  346.  ... dials up ...       <DLE>Shere              says "hello"
  347.  
  348. <DLE>S<sysname> <opts>                          says who he is
  349.  
  350.                 |       <DLE>ROK                says ok to talk
  351.                 |       <DLE>RLCK               says locked out
  352.                 |       <DLE>RCB                says will call back
  353.                 |       <DLE>RBADSEQ            says bad seq num
  354.  
  355.                         <DLE>P<protos>          what protocols he has
  356.  
  357. <DLE>U<proto>   |                               which to use
  358. <DLE>UN         |                               use none, hang up
  359.  
  360.  
  361. packet driver is turned on at this time, if not told otherwise
  362.  
  363.  -- if master has work --
  364.  
  365. to send file to slave...
  366. S <mfilenm> <sfilenm> <user> <opts>             request to send file
  367.  
  368.                 |       SY                      ok -- i'll take it
  369.                 |       SN2                     not permitted
  370.                 |       SN4                     can't make workfile
  371.  
  372. <data>                                          the file is transmitted
  373.  
  374.                 |       CY                      finished OK
  375.                 |       CN5                     can't move into place
  376.  
  377.  
  378. to recv file from slave...
  379. R <sfilenm> <mfilenm> <user>                    request to recv file
  380.  
  381.                 |       RY<mode>                ok -- here is prot mode
  382.                 |       RN2                     not permitted
  383.  
  384.                         <data>                  file is transmitted
  385.  
  386. CY              |                               worked
  387. CN5             |                               can't move into place
  388.  
  389.  
  390. to do UUX on slave...
  391. X <file1> <file2>                               request to exec file
  392.  
  393.                 |       XY                      ok -- will do
  394.                 |       XN                      nopers
  395.  
  396. to indicate that he has no more work...
  397. H                                               no more work
  398.  
  399.                 |       HN                      reverse roles
  400.                 |       HY                      no work here either
  401.  
  402. to accept slave's claim of no more work...
  403.  
  404. HY                                              agrees to hang up
  405.  
  406. the rest of the hang-up is done OUTSIDE of packet driver
  407. <DLE>OOOOOO                                     signs off (6*'O')
  408.  
  409.                         <DLE>OOOOOOO            signs off (7*'O')
  410.  
  411.  
  412. If the slave has work, then the roles are reversed, and the
  413. session proceeds from the label 'loop1' above.  The system
  414. which was the slave is now the master, and the old master is
  415. just the slave.
  416.  
  417. The <opts> which follow the system name for the start-up sequence
  418. include:
  419.         -g              don't use packet driver (command line -G)
  420.         -xN             debug level (command line -Xn)
  421.         -QN             seq number (if systems use this)
  422.  
  423. The filenames for <mfilenm> should be complete filenames with
  424. path information; otherwise they are assumed to be in /usr/spool/uucp.
  425. The filenames for <sfilenm> should be either complete filenames
  426. or directory names.  If directory names are used, then the final
  427. componant of <mfilenm> is appended to form the complete filename.
  428.  
  429. The 'X' command to do UUX on a slave is more than a little unclear.
  430. It doesn't seem to work here, but that may be a microsoft "feature".
  431.  
  432. Protocol "g", which seems to be the one most commonly used, is supposed
  433. to be a slightly munged version of level 2 of X.25; an article was just
  434. posted in net.unix-wizards (which you probably have already seen) to
  435. this effect.  The article didn't provide any details on the protocol,
  436. but merely mentioned the modifications.
  437.  
  438. The "packet" mode, with no protocol, does not work under microsoft
  439. implementations, and may have *lots* of trouble working anywhere
  440. else as well.  It evidently requires that zero-length reads happen
  441. every so often to delimit things, such as files being transferred.
  442. This of course can't happen without the packet driver, which was long
  443. gone by the time sys-3 or sys-5 or <your current version> came along.
  444.  
  445.                             Additional Comments
  446.                             -------------------
  447.  
  448. Apparently, the UUCP protocol is still proprietary information as far as
  449. AT&T is concerned.  Therefore, all the information in this file must be
  450. viewed as speculative at the worst, and 'really close' to the actual
  451. protocol at best.  During development of the OS9 port for UUCP, I found
  452. some additional information I now present.
  453.  
  454. 1.  When logging into a UNIX or UNIX-like system, it is best to always
  455.     include the name of your machine in the 'hello' message as in:
  456.  
  457.         Shere=sysname
  458.  
  459.     It seems that sone UUCP packages require this, while the others
  460.     ignore its presence.  This is not dependent on the age of the system
  461.     since I have seen newer systems (DEC ULTIRX 3.1) ignore this and
  462.     older systems (AT&T Sys V Rel 2) use it.
  463.  
  464. 2.  When logging into a UUCP site, these are the possible responses by the
  465.     remote:
  466.  
  467.         LCK                     Locked System (they're already talking?)
  468.         LOGIN                   Remote reject after login
  469.         CB                      Callback (security)
  470.         You are unknown to me   Local isn't in remote's Systems file
  471.         BADSEQ                  Bad Sequence
  472.         OK                      Everything is OK
  473.  
  474.     Anything else will give you "UNKNOWN RESPONSE" and close
  475.     down the connection.
  476.  
  477.     The system is supposed to close the connection after seeing "RLOGIN."
  478.     RLOGIN means "Remote Reject After Login."  This can happen for any number
  479.     of reasons, however the most common (with HoneyDanBer) is that the
  480.     remote system doesn't have you specified in their Permissions
  481.     file.
  482.  
  483.     The RLOGIN message can also indicate that the slave system
  484.     is not accepting logins at this time.  Try again later.
  485.     There is a schedule file that gives legal times for various
  486.     systems to call.
  487.  
  488. 3.  Many UUCP sites use Telebit TrailBlazer modems.  These very high speed
  489.     devices include the UUCP 'g' procotol within their internal ROM and
  490.     all 'g' protocol communication is done with the modem itself rather
  491.     than the host machine.  Apparently, there are some problems with the
  492.     OS9 port of UUCP and sites with these modems, where you can send data
  493.     but not received files.  To make sure this is not a problem, you should
  494.     setup the modem to NOT use its internal 'g' protocol unless the modem
  495.     it is talking to (yours) is also a TrailBlazer.  Check the documentation
  496.     for the modem to see how to do this.
  497.  
  498.