============================================================================
================= SLIP for OS/2 Frequently Asked Questions =================
================= Version 0.4 17 July 1994 =================
================= Clark K. Gaylord =================
================= CGaylord@VT.Edu =================
============================================================================
=== 7.1 ===
Q. What is SLIP?
A. SLIP (or SL/IP) stands for Serial Line Internet Protocol. It defines a
protocol for connecting to a TCP/IP network over a serial line (via a
modem or null modem). Serial communications are slower than direct
network connections, but can sometimes be useful. IBM's TCP/IP package
does support SLIP, as do FTP Software and TCP/2. There is also a port of
KA9Q that is freeware. Unless otherwise noted, this section will refer
specifically to IBM's product, though much may generalize to other
products as well.
=== 7.2 ===
Q. Is there a free (or cheap) implementation of SLIP?
A. Reputedly, yes, but I have not talked to anyone actually using it. It
is on the ftp sites as os2nosv4.zip. It is also known as PMNOS. It is a
port of KA9Q for DOS, the packet radio networking package. The KA9Q
docs should be retrieved from a DOS site as well as the binaries and docs
for OS/2.
You can also get the Trumpet Winsock implementation and run just
Winsock. This works fine, but is restricted to your SLIP being in one
WinOS2 session. Of course, you can't use OS/2 clients if you choose this
setup.
=== 7.2.1 ===
Q. How do I set up PMNOS?
A. This is a frequently asked and seldom answered question. Recently,
though, David Kraus (kraus@cig.mot.com) of Motorola posted this
information. As always, your mileage may vary.
--- Dave Kraus' stuff starts here ---
OK, here's what I have, and what I'm dealing with.
We've got a dynamic IP arrangement on our Annex server, with an ACE
security system requiring a userid and time-generated pseudo-random number
generator password. Thus, this autoexec.nos isn't going to get you 100%
logged in. It's set up to configure my port and get all of the
information other than the IP configured beforehand. Then, I do a 'tip
sl0', do modem dial commands, log in, set my IP, 'reset 1' (getting rid of
the tip session), and I'm done... Anyway, here's the AUTOEXEC.NOS, with
comments:
hostname oog.cig.mot.com
domain suffix cig.mot.com. # the trailing '.' is significant
domain cache size 40 # don't know why - I don't care if I cache
domain addserver XXX.XXX.XXX.XXX # IP of my first nameserver
domain addserver XXX.XXX.XXX.XXX # IP of my second nameserver
# The attach set to COM2, IRQ 3, slip mode, called sl0, 16k buffers, 1006 mtu,
# 38400 baud, full flow control
attach asy 0x2f8 3 slip sl0 16384 1006 38400 crv
route add default sl0 # default route setup-SLIP is point-to-point
ifconfig sl0 netmask 255.255.0.0 # Get this from your network admins
ifconfig sl0 broadcast xxx.xxx.xxx.xxx # get this from your network admins
echo refuse # something in the nosview stuff said do this for a unix system
OK, that inits things. Then I do a 'tip sl0', dial, log in, etc. as
above. When I've kicked the Annex box into SLIP mode, I go back to the
main PMNOS window, and do:
reset 1
reset 1
Why I have to reset the tip session twice, I don't know, but after the
second one, it goes away. Then I do:
ifconfig sl0 ipaddress XXX.XXX.XXX.XXX
to configure the IP that the Annex box told me for the sl0 device. Once
that's done, I'm set to start playing...
This should get you at least FTPing and telneting (albeit with a really
STUPID telnet window). As far as smtp and nntp, whatever the HAM guys say
to do should be the same. The hard part is getting the interface
configured and talking.
Build up your autoexec.nos (take out the comments - I don't know if
they're valid syntax like that; I just put them in for the example), get
your IP configured, and you should at least be able to ping to an IP. If
things look weird, do a 'domain trace on', and you'll see more information
on what's happening with the name server as it's going through it's thing.
Now, I don't want a million messages saying, "This doesn't work for me!".
This works for ME right now, given what I want to do with it. I hope it's
a starting point for everybody else. If there are commands that seem to
be 'magic', or if this whole thing is a 'magic incantation' I'd recommend
picking up 'TCP/IP Network Administration' by Craig Hunt (O'Reilly &
Associates, Inc., ISBN 0-937175-82-X), and learn the concepts behind
TCP/IP networking before you go much further. The concepts behind PMNOS
are very similar, although syntax can be rather different at times.
Remember, I'm no expert. I finally hacked at it enough over the last
couple of days to get something working with a configuration that's pretty
simplistic. My main goal was to get ftp working - nothing more. (If I want
to get into anything more, I reboot into Linux and dial back in with all
the decent tools available to me under that environment.) If you're
looking for smtp and nntp transfers, don't ask me, ask the HAMs out there
that actually use this thing...
--- END of David Kraus' stuff ---
=== 7.3 ===
Q. How do I install SLIP?
A. When you install the TCP/IP base product, SLIP support is also
installed. You can configure SLIP to start with TCPSTART by using the
Network Configuration notebook. You will need your SLIP IP node and the
destination node, if applicable.
=== 7.4 ===
Q. Do I need LAPS to run SLIP?
A. No. You only need LAPS to use an ethernet or token-ring card. If you
have a SLIP only setup, you do not need LAPS, and you can ignore warnings
to the contrary. You may need to manually edit your CONFIG.SYS, though.
=== 7.5 ===
Q. What do I need in my CONFIG.SYS?
A. The minimum CONFIG.SYS statements are:
DEVICE=X:\tcpip\bin\inet.sys
DEVICE=X:\tcpip\bin\ifndisnl.sys
RUN=X:\tcpip\bin\CNTRL.EXE
I also recommend
CALL=c:\os2\mode.com com3, 57600, xon=off, dtr=on, octs=on, rts=on,
buffer=on, databits=8, parity=none
or similar mode command. There are no environment variables that are SLIP
specific. If you have an ethernet card, you will need ifndis.sys instead
of ifndisnl.sys; ifndisnl.sys takes a little less memory, so use it if
you can.
=== 7.6 ===
Q. What is SLIP.CFG?
A. In your \tcpip\etc directory is a SLIP.CFG file. This file contains
information that SLIP reads when loading. A typical SLIP.CFG might look
like:
interface sl0
{
device=COM3,
mtu=1006,
compression=auto,
attachcmd=MySlipUp,
attachparms="555-1234 myid mypass"
}
=== 7.7 ===
Q. What SLIP utilities are available and what do I use them for?
A. SLIPTERM.EXE is a dumb terminal program that can be used while SLIP is
up. It is useful for manually connecting. SLIPWAIT.EXE will wait up to a
given amount of time or until SLIP is up. SLIPCFG.EXE is a SLIP.CFG
parser that can help you debug SLIP.CFG. SLIPHOLD.EXE holds a serial port
open when SLIP isn't active. These are all in \tcpip\bin. Also, there is
some shareware/freeware on the net, including SLIPHANG, which helps ensure
that the phone is hung up after taking SLIP down. At the time of this
writing (shortly after the release of the the second CSD for TCP/IP 2.0),
SLIPHANG reportedly causes SLIP to hang (i.e., TRAP) rather than hang-up.
=== 7.8 ===
Q. I thought I installed it right, but now it doesn't work. What do I do?
A. Disable all connection scripts (do not include an attachcmd= phrase in
SLIP.CFG). Start SLIP.EXE; start SLIPTERM.EXE. Manually connect using
SLIPTERM. After you connect, hit F10 to exit SLIPTERM. Then issue your
IFCONFIG command (IFCONFIG sl0 my.ip.node [destination.ip.node] ...) Add
your router (ROUTE ADD DEFAULT router.ip.node 1), if applicable. Look into
ROUTED (as in Route-D). Some people have found this necessary in order to
communicate with people outside their subnet.
If this doesn't work, try running MODE.COM prior to starting SLIP.EXE.
Use MODE to set DTR=ON. Also, make sure compression and mtu are correct
in SLIP.CFG. Common mtu's are 296 (especially with compression), 1006,
and 1500. You can try compression=auto, but I have also seen times when
this did not seem to work right.
Also, try a slower modem speed or turning off modem compression. This
is especially likely if you have an external high speed modem, as you may
not have a 16550 UART. You could have to tweak the modem setup quite a
bit, depending on what modem you are using, what UART you have, and what
kind of modem you are connecting to. Refer to your modem manual for more
details.
=== 7.9 ===
Q. Why do I get 'network is down' when I start SLIP?
A. The default SETUP.CMD has an ARP command in it. ARP is only used for
interface cards, so if you have a SLIP only setup, it replies that there
is no interface card by using this rather cryptic message. It shouldn't
hurt anything, but you can take it out of SETUP.CMD to prevent the
message.
=== 7.10 ===
Q. How do I get the phone to hang up when SLIP is taken down?
A. First, try fiddling with your serial port's MODE. Especially, try
DTR=ON. If this still doesn't work, get SLIPHANG off the ftp site and try
it (but, see 7.7). I also found that toggling my fax program off and on
reset my comm port and hung up the phone.
=== 7.11 ===
Q. Can I run SLIP over more than one comm port at a time?
A. Beginning with the second CSD (6/94) to TCP/IP 2.0, you can run multiple
serial interfaces. These are sl0, sl1, etc. Accordingly, some of the
SLIP utilities (e.g., SLIPTERM) now allow an interface parameter ( -sln
where n=0, 1, ....)
=== 7.12 ===
Q. How can I improve SLIP performance?
A. The best way to improve SLIP performance is to get an ethernet
connection and stop using SLIP! But assuming you really have to use SLIP,
get the fastest modem connection you can, and use your modem's
compression, especially if it is MNP 5 or above. MNP 5 and above will
almost definitely improve performance for anything except file transfers
of compressed files; MNP 5 does not usually improve these file transfers
and may hurt them. Note that V.42bis is considered "above" MNP 5.
Finally, using SLIP header compression (setting compression=on in
SLIP.CFG) may improve performance somewhat, as may increasing mtu size
(for clean connections, anyway; dirty connections may find smaller mtus to
be better). Note that when compression=on, mtu is set to 296. But if you
set compression=auto, then mtu can be anything. In some implementations,
you have two choices: mtu=296 with compression and mtu=something else
without compression. Of course, if you control both ends, then you can
fiddle with all the possible permutations; the max mtu is 2048.
=== 7.13 ===
Q. I have an ethernet connection in my office. How can I connect to my
office machine from home?
A. Try to get an IP node for the home computer. If you cannot get one
from your local IP Czar, then you can still set this up, but it is a
little more inconvenient. You will need SLIP set up on both the office
and home machine. Set the office to be in autoanswer mode (either attach
AUTOANS.CMD or go into SLIPTERM and issue AT commands manually -- don't
forget to exit SLIPTERM). Then from home, dial in. Once the office
answers, you are connected.
Now, you need to tell each end of your SLIP connection who is who.
Recall the IFCONFIG syntax:
IFCONFIG interface my.ip.address destination.ip.address
So, at the office, you would say:
IFCONFIG sl0 office.ip.address home.ip.address
and at home you would say
IFCONFIG sl0 home.ip.address office.ip.address
Then you may find you need to tell the home machine who the default router
is (i.e., the office machine). This sets up the connection.
The other issue is whether your home machine has a valid ip address.
If you cannot get a valid ip address from your local IP Czar, you can make
one up for the purposes of the office machine and home machine talking to
each other -- you just can't tell the rest of the world about it (and
don't go running routed on the office machine)! But if you have a valid
IP address for home, you may need to publish it. You do this from your
office machine with the ARP -S command:
arp -s home.ip.address xx:xx:xx:xx:xx:xx pub
where xx:xx:...:xx is the *hardware* address of the ethernet card (look in
\ibmcom\lantran.log for "node address"). This tells the rest of the world
that the way to get to home.ip.address is to send data to ethernet card
xx:xx:...:xx.
Note that if you get a subnet address for your SLIP net, then you do
not need to do this "proxy arp" maneuver.
=== 7.14 ===
Q. What REXX services are available for autoconnect scripts?
A. There are three documented functions available to SLIP scripts:
slip_com_input, slip_com_output, and slip_getch. These, respectively,
read data from the comm port, write data to the comm port, and read a
character from the keyboard without echoing to the screen. These are
documented in detail in the TCP/IP Installation and Administration Guide,
section 9.3.2.2. [How about undocumented?]
=== 7.15 ===
Q. Hitting Ctrl-C seems a bit crude. Is there any better way to end SLIP?
A. Not without rolling your own. You could help automate the process
using KILLEM or a similar process killer, but that is probably no less
crude (though may be useful for unattended or remote use).
=== 7.16 ===
Q. My phone line often drops carrier. How can I keep SLIP up?
A. The best way is to try to get cleaner connections. Have an electrician
or phone repair person check your wires if necessary. If you still have
chronic problems, you have to have some method of reconnecting when
carrier goes down.
There is no feature to automatically do this. The way some people do
this is to constantly monitor the line (using ping or similar utility).
If the line goes down, then kill the SLIP process and restart it. The
problem with this method is that you will often lose all applications
running over the interface when you kill SLIP. The way to address this is
to write a program that shares the comm port with SLIP (like SLIPTERM
does), and have it reconnect. The problem with this is that the program
interface is not documented and likely to change. Of course, if you are
sitting at the computer and hear the modem click, you just open SLIPTERM
and manually reconnect.
=== 7.17 ===
Q. I want to write a program to interface with SLIP after it is up, like
SLIPTERM does. Is there any way to do this?
A. First let me emphasize that the information here is NOT documented, NOT
supported, and LIKELY to change. So: USE AT YOUR OWN RISK AND DON'T
BITCH IF IT DOESN'T WORK! In particular, there is probably more that can
be done after the June '94 CSD. This CSD implemented a multi-interface
SLIP (allowing sl1, sl2 ... in addition to sl0) and, while the mentioned
semaphores apparently still exist, they are not interface dependent. It
seems to me there must be more, but this is all I have so far. That being
said, and you being properly forewarned, yes, you can tell SLIP to shut up
and let you use the comm port.
At the risk of implicating Dave Bolen, I would like to share his notes
on this with you:
--- Dave Bolen's stuff starts here ---
SLIP Utility Program Access to IBM OS/2 Slip Driver v1.0 -- David Bolen
The following should be done by the program wanting to tell the SLIP
driver it would like access to the COM port:
Initialization
- Check if the SLIP driver is running by opening the system
semaphore \sem32\slip\monitor.
- Open the following three system semaphores:
\sem32\slip\com\pause (com_pause)
\sem32\slip\com\paused (com_paused)
\sem32\slip\com\continue (com_continue)
COM Port Request
- Post com_pause
- Wait for com_paused
--- Access COM port ---
COM Port Release
- Post com_continue
The above should not be considered a "published" procedure or API -
but at the same time, it's what is part of v1.0. It will likely
change in subsequent versions when the SLIP driver starts supporting
multiple interfaces, and provides a more extensive functional
interface for external utilities.
Once the SLIP driver posts com_paused, although the driver still has a
shared open on the port, it will not issue any I/O requests to the
port until the com_continue semaphore is posted. Thus, any other
utility (including the one that requested the pause as is the case
with SLIPTERM) can access the port as long as they issue the DosOpen
in sharing mode (OPEN_SHARE_DENYNONE).
--- Dave Bolen's stuff ends here ---
=== 7.18 ===
Q. Can I use PPP?
A. To my knowledge, there is no PPP for OS/2 yet, though there are
constantly rumors of people working on it and IBM planning on releasing
one. Reputedly, a venture to produce a freeware TCP/IP suite for OS/2 has
begun by working on PPP. I have not heard the recent status of this.
=== 7.19 ===
Q. Where can I find out more about SLIP?
A. The docs, of course. Chapter 9 of the Installation and Administration
is all about SLIP. Also, some general TCP/IP administration books discuss
it (anyone have any specific text recommendations?) One that has been
often recommended is 'TCP/IP Network Administration' by Craig Hunt (O'Reilly &
Associates, Inc., ISBN 0-937175-82-X. Then there is RFC1055: Nonstandard
for Transmission of IP Datagrams Over Serial Lines: SLIP by J.L. Romkey,
available wherever RFCs are sold; they can be ftp'ed from nic.ddn.mil
among many other places worldwide.