SPARCbook SLIP Users Guide Tadpole Technology plc February 1992 INTRODUCTION The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard. This document describes the implementation of SLIP supplied by Tadpole Technology for the SPARCbook portable workstation. LOADING THE KERNEL MODULE The SLIP driver is supplied in the form of a kernel loadable module for the SunOS 4.1.1 and Solaris 1.0.1 (SunOS 4.1.2) operating systems. In the standard SPARCbook distribution the SLIP drivers are held in the directory /usr/slip/modules and drivers are provided for a number of architectures. In order to use SLIP services it is necessary to load the relevant module using the 'modload' command. For example on the SPARCbook the following command should be used : modload /usr/slip/modules/slipmod-sun4m.o This command may only be executed by the superuser. If the slip module has already been loaded (this may checked using the 'modstat' command) then it is not necessary to reload it. It is recommended that the module loading command be inserted into the /etc/rc.local script if SLIP will be used on a regular basis, as the module is small and will have a minimal impact on memory usage. When loading the Tadpole Technology SLIP module onto a machine other than a SPARCbook the module name will change according to the architecture under which the kernel is running. The architecture may be shown using the command 'arch -k'. Once the architecture has been established then the appropriate module may be loaded. The modules directory contains a number of modules of the form slipmod-.o each of which corresponds to one of the supported architectures. When the SLIP module has been loaded then a number of SLIP network interfaces will have been configured, each interface being allocated a name of the form 'sl'. The current release of Tadpole SLIP will always configure two interfaces, sl0 and sl1. The configured interfaces may be seen using the 'ifconfig' command : # ifconfig -a ni0: flags=63 inet 192.52.161.48 netmask ffffff00 broadcast 192.52.161.0 ether 0:0:83:1b:0:98 lo0: flags=49 inet 127.0.0.1 netmask ff000000 sl0: flags=10 <- Slip interface 0 sl1: flags=10 <- Slip interface 1 # Immediately after loading the SLIP module the interfaces will be listed as shown above ; they will not become active until a connection has been explicitly created by the superuser. This may be done either by issuing SLIP commands from a login shell or as part of the system initialization scripts. SLIP COMMAND INTERFACE The following commands may be used to manipulate SLIP interfaces and establish or break SLIP connections to a remote host. These commands reside in the directory /usr/slip/bin in the standard SPARCbook distribution. ************************************** NOTE The following commands may only be executed by the superuser. ************************************** slattach [baudrate] This attaches a slip interface to the given serial line. The device specified must be a valid character device name (e.g. /dev/ttya). The local and remote network addresses are used to identify the two ends of the SLIP link and may be specified either as numerical addresses (e.g 192.52.161.1) or by using the hostnames that are maintained in the file /etc/hosts. If the optional baudrate is specified then the character device will be changed to use that baudrate, otherwise the current baudrate will be retained. In order to complete the SLIP connection, a suitable SLIP interface must be attached to the other end of the serial connection. If the Tadpole SLIP software has been installed on the remote host then the slattach command may be used on the remote host as described above (remember to reverse the source and destination network addresses). If the Tadpole SLIP software has not been installed but an alternative SLIP implementation is available then a SLIP connection may still be possible. In this case your local system administrator should be consulted for details of the relevant configuration commands. The addresses used by the two machines to identify the ends of the SLIP link must be identical or no communication will take place. Once a serial interface is being used as part of a SLIP connection, that interface may no longer be used for normal character input or output. If the device cannot be opened or already has a SLIP interface attached to it then an error message will be produced. This command will also fail if the SLIP module has not been loaded or all of the available SLIP interfaces are busy. As well as being able to specify a character device to which the interface should be attached, a facility has been added to allow the interface to be attached to one of the standard file descriptor devices. Specifying a device name of the form '-n' will attach the interface to whichever device is connected to file descriptor 'n'. Specifying an interface of the form '+n' will perform the same function, but the SLIP daemon in control of the interface will not detach itself from the process group of the controlling shell. These options are intended to be used in the implementation of dialup SLIP and will probably not be used from the command line. sldetach This detaches a SLIP interface from its associated serial device, makes the SLIP interface available to be reused and restores the serial device to its original state. It is the complementary function to slattach, and so an equivalent command must be used at the remote end to dismantle the other half of the SLIP link. Since sldetach needs an interface name to close a connection, the name for the interface being used to maintain the particular link must be determined; this may best be done by using the 'ifconfig -a' command used above to list the active interfaces. For example a link has been established to a host 'slipB' with a network address of 192.52.160.2. The following command identifies interface sl0 as the relevant interface : # ifconfig -a ni0: flags=63 inet 192.52.161.48 netmask ffffff00 broadcast 192.52.161.0 ether 0:0:83:1b:0:98 lo0: flags=49 inet 127.0.0.1 netmask ff000000 sl0: flags=51 inet 192.52.160.1 --> 192.52.160.2 netmask ffffff00 sl1: flags=10 # slremote This command may be used to establish a SLIP connection to a remote system using a dialup line for SLIP communication. NOTE: This command may only be used to establish a connection to a host that has been installed with the Tadpole SLIP utilities. The hostname specifies the means by which the connection to the remote host should be establish, and is defined using the same mechanism as 'cu'; the relevant sections of the SPARCbook User Guide should be consulted for details of how such hostnames may be configured (particularly the sections on 'cu' and 'uucp'). Once the login procedure for the remote host has been completed the following should be checked: (1) The SLIP module has been loaded into both the remote kernel and the local kernel. This can be checked using the 'modstat' command which should report a module named 'slip'. (2) There should be a SLIP interface available to make the connection. This may be checked using the command 'ifconfig -a' which should report at least one SLIP interface that is neither UP nor RUNNING. (3) The SLIP utilities should be in the search path at both ends of the connection and superuser privileges should be available to the login shell. (4) If hostnames rather than network addresses have been issued to the slremote command, then the hosts at both ends should recognize the names. Check the file /etc/hosts if you are unsure of this. Once these conditions have been satisfied then then the SLIP link may be formed by typing the following command while talking to the shell on the remote host : ~$slbind At this point all communication with the remote host will end and slremote may be exited using the ~. command. The SLIP link is now established and will remain intact until either the line is broken or the SLIP interface at either end is terminated using sldetach. If the conditions are not met then slremote may be exited using the ~. command and no further action will be taken. COMMAND APPLICATIONS The slattach and sldetach commands are intended to be used when establishing a SLIP link onto a fixed serial connection, where direct access to both machines is available. All that is necessary in this case is to connect the two machines (either with a direct serial cable or with a modem link) and then execute an slattach command at each end in order to interface the Internet software to the serial connection. In order to close the link, the interfaces should be removed at both ends using sldetach. If a remote modem is permanently configured with a SLIP interface then a SLIP connection may be made without access to the remote host by connecting to the remote host and then executing a local 'slattach' command before the line is dropped (either from another window under OpenWindows or with the ~! escape sequence from cu). The SLIP link may be closed at a later point by performing an sldetach on the local machine. slremote is intended to be used when dialing into a login port on a remote host, to establish a SLIP link where only the local machine may be accessed. In this case the ~$slbind escape sequence will establish the SLIP link once an appropriate login has been obtained. As before the link may be closed by performing an sldetach on the local machine. USING THE SLIP CONNECTION Once the slip connection has been established, all of the standard network utilities may be used across the link, although with a much lower throughput than that provided by ethernet. By specifying the hostname corresponding to the far end of the SLIP link, all commands will automatically be routed to that host. As an example, a link has been established to a remote host using the command 'slremote sparchost slipA slipB' as described above. It is now possible to use commands such as 'rlogin paul@slipB' and 'rcp test.c slipB:/tmp' and the relevant communication will take place using the SLIP link. ROUTING TO OTHER HOSTS Once a connection has been established to a remote host, that host may be used as a gateway to other hosts on the remote network by starting the routing daemon at each end. On the SPARCbook this daemon is called 'in.routed' and must be executed by the superuser. Once the daemon has been established at both ends, routing information will be passed between the two SLIP hosts allowing other hosts at the remote end to be accessed directly from the local SPARCbook. For example, the connection to slipB has been established as described in the previous section, and 'in.routed' has been executed by the superuser at both ends (the remote end may be accessed by performing an rlogin to slipB). When this has been done, machines on the remote network may be accessed from the SPARCbook using the standard network commands : rlogin otter -l elmer ALLOCATION OF NETWORK ADDRESSES In order for the Internet software on the remote machine to correctly determine the path that a particular piece of data should be transmitted on, it is a necessary condition that the network address for each network interface on that machine be different. For this reason it is not possible to connect into a remote machine using the network address (or host name) by which it is known on the main ethernet network. The network address (more correctly termed an Internet address) is held in a 32-bit integer value and is separated into two parts, the Internet Network number and a Host Identifier. The boundary between these two fields is variable and depends on the value of the two most significant bits as follows: < Byte3 >< Byte2 >< Byte1 >< Byte0 > (Class A) [0 Net ][--------- Host ----------] (Class B) [10 ---- Net ----][----- Host -----] (Class C) [11 -------- Net ---------][ Host ] If you examine the Internet addresses of machines on your main network you should see that the Internet Network portion of all local machines is identical. It is this part that must differ for SLIP connections to operate correctly to a host connected to a local area network. Once the Network portion has been changed, host identifiers are unique to that network and so no conflict will arise with host identifiers on the main network. Ideally the system administrator for your organization will contact the authority that allocates Internet addresses to obtain a separate network address for the dialup Internet links. All such links can be covered by a single such address as described below. Alternatively a network number should be selected that will not cause any conflict with any network addresses that are accessed from your organisation. Your system administrator should also ensure that this network address is not exported to the rest of the Internet by a routing daemon. In either case a Class C network address (as shown above) should be used. If any host is capable of receiving multiple dialup connections then multiple network addresses will need to be allocated. Once a unique network address has been established, host identifiers and hostnames can be allocated as required. A host identifier should be allocated for each host that is capable of receiving a dialup connection and for each system that will be dialling in. These can be given names in the file /etc/hosts that help to collate main network and SLIP network identifiers. For example the entries for a machine 'rabbit' and a machine 'weasel' in /etc/hosts may be : 192.52.161.23 rabbit # Major Network Name 192.52.162.1 rabbit-slip # SLIP Network Name 192.52.161.24 weasel # Major Network Name 192.52.162.7 weasel-slip # SLIP Network Name In this case, when the SPARCbook 'weasel' dials up the host system 'rabbit' the connection should be established with the command : slremote dialup weasel-slip rabbit-slip ... and when the SPARCbook is connected to the main network directly the two machines can each use their original names. Note that only the two machines involved in the SLIP connection use the SLIP network names, to the rest of the network the dialup host is still called 'rabbit', and if the routing daemon is being used, all machines on the main network can be accessed with their original names from 'weasel'. If machines on the main network wish to access weasel however, they will have to use the SLIP network name and the routing daemon will route the data via 'rabbit': ----------------+------------ ethernet Network | | | 192.52.161.23 (rabbit) ________|________ | | | rabbit | |_______________| | 192.52.160.1 (rabbit_slip) | SLIP link | | | 192.52.160.2 (weasel_slip) ________|________ | | | weasel | |_______________| EXAMPLE SESSION As an example of the installation and use of a dialup SLIP connection we provide an example of a SPARCbook providing a central dialup service to remote hosts and a remote machine dialing in to establish a SLIP connection. Both the host providing the dialup facility and the remote machine are assumed to be SPARCbooks for the purposes of this discussion. Firstly the host system must be configured so that a login process is attached to the modem device, providing the standard UNIX login sequence to the user when a dialup connection is obtained. This is done by editing the file /etc/ttytab and making sure that it contains the following line: modem "/usr/etc/getty std.2400" dialup on remote secure When this has been done, the login may be established using the command: kill -HUP 1 Once this has been done, the host may be connected to a telephone point and can be dialed up from a remote host. Since this host will be used to supply a SLIP facility, the SLIP module should be loaded in advance of any users logging in, as this reduces the amount of work needed to make a SLIP connection. If at a later stage the login process needs be removed from the host modem port then simply change the 'on' to an 'off' in the /etc/ttytab entry for the relevant device and issue the kill command given above. The file /etc/hosts should also be checked and if necessary modified to specify the hostnames that will be used for SLIP connections. As an example a particular site has two Class C Internet addresses assigned for its use, one for the main local network and the other for SLIP communications. The /etc/hosts file therefore contains entries of the form : # # This site has the network addresses : # # 192.52.161.xx - Local ethernet Network # 192.52.162.xx - SLIP Network # 192.52.161.23 rabbit # SPARCbook SLIP server 192.52.162.1 rabbit-slip # SLIP Network Name 192.52.161.24 weasel # Wandering SPARCbook 192.52.162.7 weasel-slip # SLIP Network Name The remote machine may now be used to dial into the SLIP host, but before this is done, the SLIP module should be installed on the local host. The /etc/hosts files on any machines that may use SLIP networking should contain the necessary SLIP hostname definitions. Once logged in as superuser on the local host, with the SLIP utility directory /usr/slip/bin included in the local search path, the following command may be used to establish the connection to the remote host. We assume that the machine weasel is dialling up the SLIP server rabbit : weasel% su Password: weasel# slremote rabbit weasel_slip rabbit_slip rabbit% su Password: rabbit# which slattach (Check Path) /usr/slip/bin/slattach rabbit# modtstat (Check Module Loaded) Id Type Loadaddr Size B-major C-major Sysnum Mod Name 2 ???? ff00c000 2000 slip 1 Pdrv ff010000 4000 59. evq rabbit# ~$slbind ~. Connection Closed. weasel# exit weasel% ping rabbit_slip rabbit_slip is alive weasel% At this point the login to rabbit has taken place, superuser privileges have been obtained and the points in the list given earlier have been checked. With everything ready to make the connection, the ~$slbind command is issued and ~. used to return to the local shell where network commands may be used. In order to close the connection, use the command weasel% sldetach sl0 KNOWN PROBLEMS 1) The 'cu -l modem' method of talking to the modem device will not be able to open the SPARCbook modem device as it asserts the modem control signals. For this reason, add the following lines to files in /etc/uucp and use the command 'cu modem': /etc/uucp/Systems: modem Any MODEM R2400 - /etc/uucp/Devices: MODEM modem,M - R2400 spopen /etc/uucp/Dialers: spopen =,-, "" \M\pA\pT\p\p 2) The 2.01 release of the SPARCbook monitor leaves the modem in a strange state, so the first attempt to 'cu' to a remote host after power on will fail. The default configuration for the modem chipset is currently not suited to the task of establishing a login process on the modem, as it doesn't deassert DCD when no carrier is present. This means that the 'getty' will spend time talking to itself and produce REPEATED LOGIN FAILURE messages. The dialup processes will also not be dismissed when the remote machine disconnects, making the line unusable for future logins. In order to get around this, do the following before updating the file /etc/ttytab and starting the getty process : % cu modem AT OK AT&D2&C1S0=1 ~. % If a getty has been running on the modem line, then the read permissions will have been removed and must be restored with 'chmod a+r /dev/modem' before it may be accessed with cu. Note that this information will be lost if the power is cycled, and will need to be done again, but since this only needs to be executed on a server this should not be too much of an inconvenience. If the getty's are started by mistake, they should be halted by placing an 'off' in the relevant /etc/ttytab entry as described in the worked example. 3) Connection to non-SPARCbook modems may not work in the current release. This is a software problem with the SLIP module rather than a hardware problem; the modem may still be used to dial up remote hosts other than SPARCbooks for text communication. 4) When dialling into a SPARCbook using another modem, it may be necessary to force the calling modem to use a fixed speed, either 1200 or 2400 rather than negotiating automatically, as problems have been observed with automatic negotiation. Consult the manual for your modem to see how to do this. 5) If a SPARCbook is used as a dialup host, then all processes on the login should be terminated before exiting, as they will not necessarily terminate in the event of the line being broken abnormally. If the processes don't die, then the getty will not be respawned and the SPARCbook will no longer reply to dialup users. 6) It may be advisable to modify the .login initialization for the superuser so that the directory /usr/slip/bin always appears in the PATH, so that problems do not occur when the relevant executables are not found .. particularly important for dialup SLIP.