*BSD News Article 32152


Return to BSD News archive

Xref: sserve comp.os.386bsd.announce:391 comp.answers:5529 news.answers:23057
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!ctc.com!news.mic.ucla.edu!ux1.lmu.edu!s069.infonet.net!s069.infonet.net!not-for-mail
From: burgess@cynjut.infonet.net (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 8 of 10)
Supersedes: <386bsd-faq-8-772477796@cynjut.infonet.net>
Followup-To: comp.os.386bsd.misc
Date: 24 Jun 1994 12:16:41 -0500
Organization: Dave's House in Omaha
Lines: 280
Sender: burgess@s069.infonet.net
Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu
Distribution: world
Expires: 07/12/94 12:16:14 CDT
Message-ID: <386bsd-faq-8-772478175@cynjut.infonet.net>
References: <386bsd-faq-1-772478175@cynjut.infonet.net>
Reply-To: burgess@cynjut.infonet.net (386bsd FAQ Maintainer)
NNTP-Posting-Host: s069.infonet.net
Keywords: FAQ 386bsd NetBSD FreeBSD
X-Posting-Frequency: Posted on/about the 10th and the 24th of every month.

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part8

Section 7.	(System Communication and Network Information)

7.0	Communications

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

	Serial Line I/P is supported in all versions of PC BSDs.

	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.

	You will need the information in 7.4.1 below to make sense to
	you before you proceed much further.  I suggest you read that
	now.

	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.  [Ed.Note - I have; it is.]
 	  A fairly common problem on the server is an error that is 
 	  caused by the lack of a 'sliplogin' entry in the /etc/shells
 	  file.  Be sure to add sliplogin to your shells file.

	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 background it if your line wants to
	    drop once the device is closed).
	  - Run `slattach /dev/comport` for whatever "comport" is.  On most
	    BSD derived systems, this may be either com0, or cua01, or
	    whatever the correct name is for your site.

	  If you run into an error that says 'not configured' in it, your 
	  kernel either does not recognize your port (dmesg will verify that)
	  or your kernel does not have the slip interface built in.  See 
	  below for the latter.  The former could be caused by any one of 
	  a dozen problems, including conflicting or incorrectly identified 
	  IRQs or port addresses.

	  - Run `ifconfig sl0 net 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	PPP

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

	It should also be noted that there is a newsgroup that covers the 
	PPP protocol exclusively.  It is comp.protocols.ppp.


7.3	TCP/IP

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


7.4	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 derived BSD systems.  Look in the 
	/usr/src/gnu/libexec/uucp directory for more information.  You 
	can also look in the /usr/share/doc/smm/09.uucpimpl and 
	/usr/share/doc/smm/21.uucpnet if yours are populated.

	
7.4.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

	Make sure that, if you are running newsyslog, you change the 
	owner.group entry in the newsyslog.conf file so that the file
	ownership is maintained correctly.

	Then you should be all set, remember "DOS Com1" = com0, and 
	"DOS Com2" = com1.  So, if your modem is at 0x2F8/IRQ=3 and you
	access it as the COM2: port from DOS, 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.  If
	this file already exists and is owned correctly, make sure that the
	lock file in the directory is deleted.

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


7.4.2	What is the magic incantation that allows the modem to dial?

	Try 'stty -f /dev/tty0? clocal'.  Change the '?' for whatever 
	character is appropriate for your tty port.  Remember, DOS COM1 = 
	/dev/tty00 and DOS COM2 = /dev/tty01...

	Some other things that might cause some problems are the entries
	in the /etc/remotes file.  Try 'com?:dv=/dev/tty0?:br#19200:pa=none'
	and see if that helps.  Remember to replace the '?' with '[01234]'
	as appropriate.

	NetBSD-current has implemented the 'ttyflags' program.  This
	will set your com ports according to the options specified in
	the /dev/ttys files.  This is an even better solution than the
	'stty ... clocal' fix from above!

7.5	Terminals

	Since the target machine for most BSD 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 (4 to 5 
	and 6 and 8 to 20) 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 BSD derived systems.  Without this
	handshaking (particularly pins 6, 8, and 20) your ports may appear
	to be dead.  This is because most of the tty driver for *BSD 
	systems require a Data Carrier Detect to be active before the
	port will work.

	For those folks that have hardware flow control working, you need
	to look in the man page for 'stty' and look around for the 
	-clocal and -ctrcrts options.

	Once the cable is set up, you will need to make sure that your
	system is ready.  The first thing you will need to do is make all
	of the devices in the /dev/ directory.  A program, called MAKEDEV,
	is available in the /dev directory.  Running this program with 
	the argument 'tty' will make all of the physical tty devices.

	With that done, arranging for a 'getty' on the port is the next 
	order of business.  You will need to edit the '/etc/ttys' file
	and make one of the tty devices available.  If you have 
	connected your terminal to DOS COM1, you will be enabling 
	/dev/tty00.  Similarly, if you are connected to COM2:, you will
	be enabling /dev/tty01 (see the pattern?).  There are other
	names for those ports as well, but when you are talking about 
	terminals, be sure to use the '/dev/tty*' names.  If not, you 
	will be completely ignored and treated as an outcast because 
	you obviously have not done any of your homework.

	One of the other common problems with the SIO driver is that 
	people will often disable all handshaking, and then complain
	that they cannot get a reliable connection above 9600 baud.  
	Handshaking is the solution to most of these problems.



7.6	Can network attached assets be used by/from NetBSD?

	Yes, they can, assuming the machine at the other end of the 
	connections is reasonably cooperative.  The specifics are up to
	the remote machine, but a couple of things that you can start 
	looking for that will help are provided below:

		-  Ask the system administrator of the machine in
		   question if it is OK for you to use whatever it is 
		   you need.  This is more a matter of manners than a 
		   technical issue. 

		-  For NFS mounted disk drives, make sure that you are 
		   not prevented from using the assets by the 
		   /etc/exports (or equivalent) file.  This goes for 
		   CD-ROMs as well as regular mounted disks.

		-  There are a completely different set of concerns for
		   tapes and printers.  Each system implements these in
		   slightly different ways.  Check with your system 
		   manager or documentation for more information.

	Note that not all network clients are created equal.  There may
	be semantic differences between what you EXPECT to happen and
	what actually happens.  Your best bet at that point os to get
	with the local system manager and talk to him or her about what
	you should be expecting on the system and what is actually
	happening.  An excellent example is the semantics of file group
	accounts when a new file is created on an NFS machine.  The
	semantics of the create will be based on the OS on the SERVER,
	so it will be whatever SysV or Sun thinks is correct, not what
	we expect from the BSD side.

-- 
TSgt Dave Burgess           | Dave Burgess
NCOIC, USSTRATCOM/J6844     | *BSD FAQ Maintainer
Offutt AFB, NE              | Burgess@cynjut.infonet.net or ...@s069.infonet...