[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]


..[ Phrack Magazine ]..
.:: Advanced Bitnet Procedures ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ]
Current issue : #24 | Release date : 1989-02-25 | Editor : Taran King
Phrack Inc. XXIV IndexKnight Lightning & Taran King
Phrack Pro-Phile XXIV Featuring Chanda LeirTaran King
Limbo To Infinity; Chapter Three of FTSagaKnight Lightning
Frontiers; Chapter Four of FTSagaKnight Lightning
Control Office Administration Of Enhanced 911 ServiceThe Eavesdropper
Glossary Terminology For Enhanced 911 ServiceThe Eavesdropper
Advanced Bitnet ProceduresVaxBuster
Special Area Codesunknown
Lifting Ma Bell's Cloak Of SecrecyVaxCat
Network ProgressionDedicated Link
Phrack World News XXIVKnight Lightning
Phrack World News XXIVKnight Lightning
Phrack World News XXIVKnight Lightning
Title : Advanced Bitnet Procedures
Author : VaxBuster
                                ==Phrack Inc.==

                      Volume Two, Issue 24, File 7 of 13

               ()()()()()()()()()()()()()()()()()()()()()()()()
               ()                                            ()
               ()         Advanced Bitnet Procedures         ()
               ()                                            ()
               ()                     by                     ()
               ()                                            ()
               ()          VAXBusters International          ()
               ()                                            ()
               ()()()()()()()()()()()()()()()()()()()()()()()()


Greetings!  I have taken the time to write up a file about some of the more
complex operations on Bitnet.  I hope you enjoy it!                         :-)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

You can send multiple messages to one user@node under VAX/VMS & JNET by just
typing;

          $ SEND/REMOTE <host> <user>

This will collect messages from the terminal until an empty line or CTRL-Z is
entered.

Under Unix, the UREP package is popular to connect Unix boxes to Bitnet.  The
important user commands are as follows:


Messages
~~~~~~~~
netwrite user@host

Send one or more messages to the specified Bitnet user.  Netwrite reads
messages from it's standard input until an EOF is reached.  If called from a
terminal, netwrite will terminate on an empty line as well.

When you receive Bitnet messages on a Unix host, UREP looks for an executable
file named .exwrite in your home directory.  If it doesn't find such a file,
the message is simply spit on your terminal.  If .exwrite is present, UREP
executes this program (which can be a shell script) with five parameters:

        <To System> <To User> <From System> <From User> <Tty>

The <Tty> parameter tells the terminal to which UREP wanted to send the
message.  UREP then feeds the messages to .exwrite as standard input.  The
format of standard input is as follows:

        <count (1 byte)><message (<count> bytes)>

To display these messages you need to have a "C" program, since a shell script
is not capable of handling single bytes painlessly.  I included my exwrite.c at
the end of this file for a start.

Typically, .exwrite is used to log all incoming Bitnet messages.  You can of
course blow it up to send messages back to the sender when you're out to lunch,
etc. BTW, .exwrite is called with the user ID of the receiving user, so it's no
real security hole.


File Transfer
~~~~~~~~~~~~~
netcopy user@host [ options ]

Copy a file to the specified Bitnet user.  The most important option is
"name=<fname>.<ftype>", with which you can specify the file name to be used
at the recipient's machine.  More details are in the manual page.

When you receive Bitnet files on a Unix machine running UREP, they will
be placed in your home directory under the name ":<fname>.<ftype>".  These
files are in NETDATA format, and they have to be converted to ASCII text files
when you want to use them under Unix.  This can be done with the command;

netdata [ <input_file> [ <output_file> ] ]

When <input_file> is unspecified, standard input is used.  If <output_file> is
unspecified, standard output is used.


Bitnet Commands
~~~~~~~~~~~~~~~
Though Bitnet has no remote login capability, you can execute a (restricted)
set of commands on remote hosts.  These commands can be used to query node
status, lists of logged-on users, time and some other things.

This works as follows:

        JNET:   $ SEND/COMMAND <host> [ <command> ]
        UREP:   % netexec <host> [ <command> ]
        CMS:    SMSG <server> CMD <host> <command>

The <server> under CMS is the Bitnet control process.  In Europe, it is
normally called "EARN."  In the USA, it could be "BITNET" or maybe "RSCS."
You're on your own here.

The <host> is the Bitnet host name which you want to execute the <command>.
With JNET and UREP, you will be asked for multiple commands when you leave the
<command> field empty.  Again, input is terminated with EOF or an empty line.

I have found the following commands useful in daily life:

        CPQ N           Get a list of the users currently logged in at the
                        <host>.  This command is supposed to exist on every
                        Bitnet host, but some system managers like to restrict
                        it for security reasons.  On JNET and UREP hosts,
                        FINGER performs a similar, but more elaborate function.

        CPQ T           Make <host> tell you the current time at it's location.

        Q <otherhost>   Make <host> tell you what the next hop to <otherhost>
                        is.  This is useful when you're interested in the
                        network topology.

        Q <ohost> A     This makes <host> tell you what file is currently
                        active (being transmitted) for <ohost>.  This only
                        works for machines which are directly connected to
                        <host>.

        Q <ohost> Q     This makes <host> show you the queue of files currently
                        waiting for transmission to <ohost>.  This is useful
                        when you want to trace some file which you sent to the
                        network.

        Q SYS           This makes <host> tell you about the RSCS links it has.

Unfortunately, MVS-Hosts don't understand any of these commands, but simply
give an error message.  You can recognize these things by the string "HASP"
somewhere in the error message.

        Enjoy !

exwrite.c For Unix Hosts Running UREP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<-- cut here -->
/* exwrite.c - formatter for UREP rscs messages                         */

include <stdio.h>
include <sysexits.h>
include <pwd.h>
include <ctype.h>

main(argc, argv)

        int             argc;
        char            *argv[];
       struct  passwd  *pw;
        char            fname[255];
        FILE            *term;
        FILE            *log;
        int             count;
        char            buf[1024];
        char            *from_user;
        char            *from_host;
        char            *to_user;
        char            *to_host;
        char            *to_tty;
        char            *home_dir = "/tmp";

        if (argc != 6)
                fprintf(stderr, "%s: Invalid arguments\n", argv[0]);
                exit(EX_USAGE);


        /* initialise variables                                         */
        to_host = argv[1];
        to_user = argv[2];
        from_host = argv[3];
        from_user = argv[4];
        to_tty = argv[5];

        /* convert the receiving user to lowercase.  Under Unix, all    *
         * user names normally are lower case, and we need a valid      *
         * user name to determine the home directory                    */
        for (; *to_user; to_user++)
                *to_user = tolower(*to_user);
        to_user = argv[2];

        /* get the home directory of the receiving user                 */
        if (pw = getpwnam(to_user))
                home_dir = pw->pw_dir;

        /* open the terminal, exit if the open fails                    */
        sprintf(fname, "/dev/%s", to_tty);
        if (!(term = fopen(fname, "w")))
                exit(EX_OSERR);

        /* open the rscs log file                                       */
        sprintf(fname, "%s/.rscslog", home_dir);
        log = fopen(fname, "a");

        /* if the message is not coming from the relay, write the       *
         * sending user and host name to the specified terminal         */
        if (strcmp(from_user, "RELAY"))
                fprintf(term, "From %s@%s:\r\n", from_user, from_host);

        /* read in the RSCS messages and send them to the terminal      *
         * and to the logfile if it has been opened.                    *
         * In the log file, all lines are preceded by the sending user  *
         * and host name.                                               */
        while ((count = getchar()) != EOF)
                if ((count = fread(buf, 1, count, stdin)) > 0)
                        fwrite(buf, 1, count, term);
                        fprintf(term, "\r\n");
                        if (log)
                                fprintf(log, "%s@%s: ", from_user, from_host);
                                fwrite(buf, 1, count, log);
                                fprintf(log, "\n");




        exit(EX_OK);
_______________________________________________________________________________
[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]
© Copyleft 1985-2021, Phrack Magazine.