From: erc@apple.com (Ed Carp) Subject: Re: SLIP: Someone has it running? Date: Tue, 10 Aug 1993 06:12:15 GMT
Martin-D. Lacasse (isaac@elrond.physics.mcgill.ca) wrote:
: Has someone been able to get SLIP running? I first tried with
: pl11, but it turned out that the compressed function was not
: properly removed while recompiling the kernel and the terminal
: server I use (Cisco) is not configured to support compression.
: I applied the fix, could get rlogin working, but it freezes
: after one page or so of data. Then someone told me to get some
: patches for net-2 but these seem to only apply to pl10. (net-2e)
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.os.linux
Subject: Re: SLIP FAQ?
Message-ID: <Aug.3.04.35.05.1993.11779@geneva.rutgers.edu>
Date: 3 Aug 1993 08:35:06 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 276
erc@apple.com (Ed Carp) writes:
>A while back, Charles Hedrick posted a most excellent FAQ on EXACTLY how to
>get SLIP running. Unfortunately, I have misplaced the FAQ, and have not seen
>it reposted. Could some kind soul, possibly charles himself, please forward
>me a copy? Thanks in advance!
These are instructions for configuration SLIP, for 0.99pl10 or pl11 with
the net2 utilities. At the end there is a list of common problems
and solutions.
sohail@trixie (Sohail M. Parekh) writes:
>a) Do I need to upgrade my GCC and LIBC. Since I have SLS 1.0 I think
> I have gcc 2.3.3 and libc.4.3.. Is this needed for 0.99p10 or NET-2
> or both ???
I'm using it with libc4.3.3 and gcc 2.3.3. (I since upgraded to
libc 4.4.1 and gcc 2.4.3 with no trouble, though since I haven't
recompiled anything the gcc version probably doesn't matter.
There have been some reports of problems compiling 0.99pl10 with
gcc 2.3.3, so Linus recommends using a newer GCC. I didn't see
any trouble.)
>b) Is their any easy config guide for NET-2 ? I down load the binaries
> (base+ext+std) from tsx-11 and base has alot symbolic links pointing
> to /conf/xxxx which does not exist ???
This depends upon the programs you want to use. For the set I use
(which is just the more common ones), all I seem to need is hosts,
host.conf, and resolv.conf. The rest of them are files for specific
services or specific options of services, which you may not need in a
simple SLIP environment. (E.g. exports is for running an NFS server,
not very likely over SLIP.) The way I have it set up is with
the following files on /etc:
hosts: a single line listing my host only (seems to be needed by dip):
128.6.200.2 foo.rutgers.edu foo
Obviously you'll use your own IP address and host name. You give the
IP address, the full hostname, and the abbreviation (i.e. just the
part up to the first dot). In the case of SLIP, it's possible that
you won't know your IP address until you dial. Often it is assigned
dynamically at that point. In that case, the hostname will be
different each time also. You can consider using a fake hostname,
e.g. your own name. The hostname you use won't matter unless you use
services that cause you to pass a hostname to the other end, e.g.
mail, news, and the Berkeley r commands. For simple telnet and ftp it
doesn't matter. (I always call my machine hedrick.rutgers.edu, but
I'm not using any fancy services.) If you need to use services that
depend upon a hostname, you'll need to arrange a real entry in your
host table. Talk to your network managers.
host.conf: one line specifying the order in which to use the hosts
file and the resolver. I suggest
order hosts bind
resolv.conf: your domain and nameserver. For Rutgers this would be
domain rutgers.edu
nameserver 128.6.4.4
The domain is what you want to be tacked onto the end of host names
you type if you don't say otherwise. E.g. if domain is set to
rutgers.edu, and you say "telnet foo", you'll get foo.rutgers.edu.
You can of course always specify a full name and override that
default. The nameserver is the address of a machine that will provide
name service for you. You'll want to pick the nearest name server to
the system you dial into. Your systems support staff should be able
to help you here. One approach would be to look at /etc/resolv.conf
on a system you commonly use. 128.6.4.4 will actually work from
elsewhere, but it's considered unfriendly to do name lookups
across the network. (I'd say it's OK to use for testing purposes,
but you should find a server at your site.)
>c) If and when I have 0.99p10 + upgraded gcc (if needed) + NET-2 running,
> how do I get SLIP up and running (boy I am greedy!).
>I have noticed alot postings about problems with configuring NET-2 and a few
>that indicate that they got passed that, but none that says how do you
>configure NET-2. So any help will be much appreciated. Thanx in advance.
If you have the three files I mention set up, I think all you need to
do is
1) dial using kermit or some other program. Get SLIP turned on. (I
can't help with that. It depends upon the system you're using.)
2) if it assigns different addresses each time, edit /etc/hosts to
get the right address
3) run dip. E.g.
dip -t
remote 1.2.3.4
port tty65
speed 19200
mode SLIP
for 1.2.3.4 use the IP address of the system you have dialed. Not the
address it assigns for your machine, but the address of the terminal
server or Unix box that is running SLIP for you.
for tty65 use the name of the tty line on your machine (probably
something like ttys0)
for 19200 use whatever speed your modem is set for
4) dip will exit. "ps agx" should show that it is still running. Now
/etc/route add default 1.2.3.4
/usr/etc/inetd
where 1.2.3.4 is the same address you used above. Run inetd only
if you want incoming services. For initial testing, I wouldn't use it.
5) now try some tests, e.g.
ping 1.2.3.4
or
telnet 1.2.3.4
Now try it with a hostname
ping foo
or
telnet foo
Finally, it this works, and you want better performance, see if the
system you are connecting to supports header compression (sometimes
called Van Jacobson header compression or CSLIP). If so, go to
athos.rutgers.edu and get /pub/linux/slhc.tar. There is a readme
telling how to install it. (This applies only to pl10. pl11
already has this patch installed.)
=================
Here's a list of common problems and solutions:
1) connections open, but no data flows. For this problem to apply,
it must apply for all destination hosts, and no data must flow at
all.
- probably your system and the SLIP router disagree about
the setting of header compression. Note that 0.99pl10
as originally issued does not have header compression.
There is a patch that I put on athos.rutgers.edu. If
you put it in, you always have header compression.
I had hoped that in 0.99pl11 it would be under the
control of an option in ifconfig, but I have some reason
to think that in some versions of the kernel, it may
be always on.
- to fix this, you must change the setting on either your
system or the SLIP router. The ideal situation is
to enable header compression on both. If you have
0.99pl10, you can enable compression by applying
the patches in athos.rutgers.edu:/pub/linux/slhc.tar.
In later versions I believe header compression is either
on or controllable in some way. If you can't enable
compression on the SLIP router, then you have to
disable it on Linux. With the initial 0.99pl10,
it is disabled. If you applied my patch, it enables
header compression. To disable it: look in slip.c for
the routine sl_encaps. remove the line that calls
sl_compress. That should be all that's needed.
- in 0.99pl11, header compression is on by default.
to disable it, look in slip.c for
the routine sl_encaps. remove the line that calls
sl_compress. That should be all that's needed.
- note that header compression makes a major difference
to responsiveness of the system. I would not be
interested in SLIP without header compression. Echo
delay is just too painful. You might want to consider
kermit or term if your SLIP router doesn't understand
header compression. (On the other hand, header
compression is widely available, so I'd think you
should be able to enable it on the SLIP router.)
2) connnections open, data flows, but wherever I try to send
more than a few lines of output, the connection hangs.
- this is probably an MTU problem. Probably the host you
are talking to is sending 1500-byte packets, and
the SLIP router is set to something smaller. (Berkeley
SLIP defaults to 1006.) In that case, the SLIP router
will fragment the packets. Linux TCP/IP can't
reassemble fragments.
- In dip, specify a smaller
MTU. I believe 512 should be safe. I normally use
192. This is probably counter-intuitive. Since the
problem is with accepting large packets, you'd probably
think the solution would be to raise Linux's MTU to
1500 so you can accept a full 1500 byte packet.
The problem is actually an interaction between the
Linux system and the SLIP router. It isn't that
Linux is incapable of handling large packets, but that
the SLIP router isn't, and is fragmenting them. What
you need to do is make sure that neither end sends
packets large enough that they need to be fragmented.
When a TCP connection opens, the two ends tell each
other what the maximum packet size they want is. They
then use the minimum of those. So by setting the
Linux MTU to 512 or 192, Linux will tell the other end
to use a small packet. Thus fragmentation won't happen.
Another approach would be to increase the MTU on the
SLIP router, so it doesn't fragment the packet.
In many cases this may not be practical.
3) Things work erratically. Connections open, but eventually
hang. Timeouts shown in netstat -o are long. Typically you'll
have more trouble with hosts on the Internet than with local hosts.
- the TCP code in 0.99pl10 is buggy. It doesn't compute
retransmission times correctly. Sometimes it will get
into a state where it never retransmits. I believe this
is fixed in 0.99pl11, but I can't say for sure, as I haven't
use it. (It's possible that pl11 fixes this and introduces
a different bug.)
- if you have unmodified 0.99pl10, apply the patches in
athos.rutgers.edu:/pub/linux/slhc.tar. Aside from
compressed SLIP, this has a number of fixes to TCP/IP.
Note however that if you apply these fixes as is, you're
enabling header compression. If this causes problems
(see (1)), you may need to disable header compression.
4) I'm not sure what the exact symptoms for this one would be, but
they might be similar to 2 or 3. I.e. some things would work, but
there would be erratic failures or hangs.
- flow control must be set up properly between the computer
and modem. Thus is true at both ends. (Of course flow
control is only one possible problem in modem setup.
You also need to make sure that the modem and line
speeds match, etc.) In general if you're using a
simple v.32 modem, you may be able to do without
flow control. However if your modem does error
control, compression or speed-matching, then you'll need to
talk to it at a higher speed than the data is actually
transferred at, and depend upon flow control to throttle
the data. At any rate, the modem and computer must agree.
- the only flow control that is practical for SLIP is
hardware flow control. Flow control using ^S/^Q
(XOFF/XON) is not practical. The most common kind of
hardware flow control is RTS/CTS, so called because
it uses the RTS and CTS lines to handle flow control.
The version of "dip" I have seems to set RTS/CTS
flow control all the time (which is certainly
appropriate). In that case, you'd want to make sure
that the modem used with your Linux system has
RTS/CTS flow control enabled.
5) I get "no route to host" or something similar.
- probably you don't have a default route. by default dip
sets up a route to the SLIP router, but nothing else.
- You need to do /etc/route add default A.B.C.D, where
A.B.C.D is the address of your SLIP router. (This
should be the address shows as "point-to-point addr"
if you do /etc/ifconfig sl0.) The default netmask
also seems wierd, but in a typical SLIP setup it
shouldn't matter.
--
Ed Carp, N7EKG erc@apple.com 510/659-9560
anon-2133@twwells.com
If you want magic, let go of your armor. Magic is so much stronger than
steel! -- Richard Bach, "The Bridge Across Forever"