*BSD News Article 21084


Return to BSD News archive

Xref: sserve comp.os.386bsd.announce:112 comp.answers:1956 news.answers:12126
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: burgess@hrd769.brooks.af.mil (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: comp.os.386bsd.announce Frequently Asked Questions (Part 7 of 9)
Followup-To: comp.os.386bsd.announce
Date: 15 Sep 1993 13:50:57 -0000
Organization: Armstrong Laboratory, Brooks AFB, TX
Lines: 177
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 10/03/93
Message-ID: <386bsd-faq-7-748101047@hrd769.brooks.af.mil>
References: <386bsd-faq-1-748101047@hrd769.brooks.af.mil>
Reply-To: 386bsd-faq@hrd769.brooks.af.mil (386bsd FAQ Maintainer)
NNTP-Posting-Host: hrd769.brooks.af.mil

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part7

Section 7.	(System Communication)

7.0	Communications

	386bsd and its kith support a wide range of communications methods.
	
7.1	SLIP

	Serial Line I/P is supported in all versions of Net/2 derived BSD.

	Brian <brian@awfulhak.demon.co.uk> provides us with a rather
	good explanation of some of the hurdles that must be overcome
	for a working slip interface.

	The idea is (overview) that you make a serial line connection to 
	the host, set the line discipline, and tell your router to use 
	this interface as your gateway.  You also should set the gateway 
	up as a nameserver.

	Sounds easy ? - well it is if you've done it before.

	The _usual_ way of doing this is as follows:

	Both server and client must know eachothers inet addresses.  Set 
	these up in /etc/hosts with lines saying
	    11.22.33.44 host.my.domain.name host
	    11.22.33.55 client.my.domain.name client

	where 11.22.33.?? is your inet number, and the following name is 
	the full machine name (and is followed by any number of aliases).

	SERVER:
 	  Create a login - usually Sclientname - and run `sliplogin` as 
 	  its shell.  I've looked at the docs for sliplogin, and it seems
 	  fairly straightforward.  I haven't actually set up a server.

	CLIENT:
	  Set up /etc/resolv.conf to say the following (for the nameserver)
		domain client.my.domain.name
		nameserver 11.22.33.55

	  ** traditional method **
	  - Log on to the server.  This is usually done via kermit or some
	  such program.
	  - Exit the program (or backround it if your line wants to drop 
	  once the device is closed).
	  - Run `slattach /dev/comport` for whatever "comport" is.  On most
	    Net/2 derived systems, this may be either com0, or cua01, or
	    whatever the correct name is for your site.
	  - Run `ifconfig inet sl0 clientname servername netmask 0xffffff00`
	  - Run `route add default servername`.
	  
	    "servername" is your server and "clientname" is your client.
	    
	  It should now be possible to `ping host`

	** my method **
	  Configure /etc/remote
	  Configure /etc/host.dial
	  Run `slip host`.

	/etc/remote contains an extended `tip` entry.  /etc/host.dial 
	contains a login script (and is named in /etc/remote).

	Oh yes, don't forget to have a line in your kernel config saying

	pseudo-device sl 2

	Without this line, you may get a 'device not configured' or 
	'TIO...' error because the slip driver is not built into the 
	kernel.

	I uploaded the slip package a while ago (to several archives), but 
	was unaware of needing to notify the postmaster.  They've probably 
	all been removed now.  Slip packages are available from many FTP 
	sites; use archie to find the site nearest you.


7.2	CSLIP

	SLIP is included in the NetBSD-0.9 stock kernel and in the source
	tree.


7.3	PPP

	Implementations of Point to Point Protocol are also available.  PPP
	should be available in the next major release (0.9+) of NetBSD.


7.4	TCP/IP

	TCP/IP is an integral part of Net/2 BSD.  There are at least five
	different network card drivers.  TCP/IP is fully supported and is
	available to all users of Net/2 derived BSD systems.  In fact,
	many people believe that this area is one of the primary advantages
	that Net/2 has over Linux.


7.5	UUCP

	There is an excellent document included in the UUCP directory
	that describes in detail, what needs to be done to get a working
	UUCP for Net/2 BSD systems.

	
7.5.1	TIP/CU

	First thing you need to do is...

		vi /etc/remote

	Then remove the two lines at the bottom of the file that mention 
	com1, and com2.  Now add the following lines:

		com0:dv=/dev/com0:br#9600:
		com1:dv=/dev/com1:br#9600:

	That tells tip/cu where to find your com ports.  Next you need 
	to be logged in as root and do a:

		chown uucp.dialer /dev/com0
		chown uucp.dialer /dev/com1
		touch /var/log/aculog
		chown uucp.dialer /var/log/aculog

	Then you should be all set, remember "DOS Com1" = Com0, and 
	"DOS Com2 = Com1".  So, if your modem is at 0x2F8/IRQ=3 you would do..

		tip com1

	To exit, type <RETURN>~.<RETURN>

	Many people have a problem with the lock open: procedure.   
	If you receive the error:

	lock open: no such file or directory
	all ports busy

	You need to create a directory: /var/spool/lock, owned by uucp.

	This answer thanks to (crt@tiamat.umd.umich.edu).


7.6	Terminals

	Since the target machine for most Net/2 machines is a 386 with 
	no more than a couple of serial ports, most people do not bother 
	with serial terminals.  For most problems, a quick perusal of the 
	man pages for the ttys file and getty are enough to get them 
	started.  Other than that, most terminal problems are limited to
	peculiarities of particular terminals.

	One common problem that appears to crop up from time to time is
	which wires need to be connected at each end of the cable.  Most
	cables do not, in fact, pass through all lines.  If your terminal 
	uses XON/XOFF (DC1/DC3) protocol, a cable of the appropriate 
	twist, either straight through or null modem, can have as few as
	three lines connecting the two devices.  Assuming DB-25 connections
	at each end, the lines need to go from 2 to 3, 3 to 2, and 7 to 7.
	These lines are Rx, Tx, and gnd.  Other lines that may or may not
	be required include 4 and 5; and 6, 8, and 20.  Normally, these 
	lines would be connected within the 'hood' of the cable to simulate
	the functionality of the full blown cable.  While full support for
	CTS/RTS is not available (yet), other support for the remainder
	of these lines is available or is being worked on in all Net/2
	derived systems.
	

-- 
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX