*BSD News Article 10542


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA279 ; Sun, 31 Jan 93 14:00:57 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!ames!nsisrv!Pt!postmaster@hq.af.mil!rick
From: rick@postmaster@hq.af.mil
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] SLIP and NET configuration
Message-ID: <16721@hq.hq.af.mil>
Date: 27 Jan 93 14:10:43 GMT
References: <53@meadmc.async.vt.edu> <CJB.93Jan20090705@orchid.cs.uq.oz.au>
Sender: news@Pt.hq.af.mil
Reply-To: rick@hq.af.mil
Organization: 7TH Communications Group
Lines: 90

In article <CJB.93Jan20090705@orchid.cs.uq.oz.au>, cjb@cs.uq.oz.au (Christopher J Biggs) writes:
|> I too have temporarily given up trying to figure out how to run slip.  All I want to 
|> do is connect two pc's running 386bsd (or maybe (not on MY machine!) OS-half) via
|> slip.  I wonder could somebody provide a quick explanation of how to choose host numbers
|> and names, where to put them, and what the config files look like...
|>   
|> ------------veni vidi nuclei deceiri - I came, I saw, I dumped core------------

This was a real mess for me also. I did get it working though.

I am used to the ifconfig command on a normal ether type interface so
trying to get slip configured was a bit confusing to me too.

I don't know why, but this is what I have had to do to get the slip stuff
to work on my system: Packard Bell-386SUX, 4 Mb RAM, 130 MB IDE.

First I use tip to connect to the far end. In my case I am not connecting to
a host that runs slip, but rather a slip capable modem/niu. Because of this
I know what my IP address will be, so I set up my 386BSD system to use
this IP address. (do this by putting my host name in /etc/myname and
adding an entry to the /etc/hosts file with the ip address used. In my case
134.205.122.28)

# tip phone_number

Once connected to the far end--

CS> slip 134.205.122.28

Then I do a "~." and come back to the local host.
(Be sure to force CD "on" on the modem or when you ~. it will
drop the connection.)

This is what doesn't make sense to me but works.
Remember I tell the slip modem I want 134.205.122.28
then set my 386BSD host ip to 134.205.122.28, then

# slattach /dev/com2 9600
# ifconfig sl0 134.205.122.28 134.205.122.28
# route add default 134.205.122.28
# ping hq  
PING hq.hq.af.mil (134.205.123.148): 56 data bytes
64 bytes from 134.205.123.148: icmp_seq=0 ttl=255 time=510 ms
64 bytes from 134.205.123.148: icmp_seq=1 ttl=255 time=510 ms
64 bytes from 134.205.123.148: icmp_seq=2 ttl=255 time=510 ms
64 bytes from 134.205.123.148: icmp_seq=3 ttl=255 time=510 ms
64 bytes from 134.205.123.148: icmp_seq=4 ttl=255 time=510 ms
64 bytes from 134.205.123.148: icmp_seq=5 ttl=255 time=510 ms

^C
I don't really know why this works, if someone does they may
want to enlighten me. I am assuming that the sl0 interface
works a little differently than say we0.

Caveats here are that if you are using a host on the far end
for slip rather than an NIU this may not work-- I dunno
I haven't tried it. 

Other things I have noticed. Once I applied all of the patches from the
patchkit relating to the com driver, slip wouldn't work at all anymore.
However tip and cu would.

So I dumped the distribution com driver.
The driver I use is Chris Demetriou's and I don't have a 16550 UART,
so I do the #define's accordingly. I get plenty of COM SILO Overflows.
NFS hangs over slip, rlogins and telnets work okay, ftp is slower
than molasses in the winter time, but will eventually transfer the file.
Sendmail works as well as most other network services.

I bought a 16550 UART but 386BSD doesn`t seem to recognize it. 
My com ports by default are made onto the motherboard. So I 
disabled com2 and popped in the 16550 UART add-in board, adjusted the com.c driver 
rebooted, 386BSD recognized com2 and I still get com silo overflows.
Yes I tried going back to the default com.c with all of the patches from
the patch kit and the damn thing again didn't work at all. 
Next I am going to see if the com driver actually recognizes the UART
as a 16550.

I noticed on the new UART that the chip is numbered NS16550AFN. Could
this be my problem ( meaning NS16550AF versus NS16550AFN )?
If anyone knows about this sort of ouija magic I would appreciate 
a little enlightment. Sorry if this post got lengthy but I have been
dinking with this slip mess for a while.

Hope this helps someone out.
Thanks,
-- 
Rick Weldon     I-NET Inc. (Pentagon, 7TH Com Group)
E-mail: rick@hq.af.mil
Phone:  703-695-5060