Return to BSD News archive
Xref: sserve comp.os.386bsd.announce:195 comp.answers:2933 news.answers:15282 Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!news.dell.com!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] BNR/2 derived BSD for PCs FAQ (Part 8 of 10) Followup-To: comp.os.386bsd.misc Date: 13 Dec 1993 06:02:37 -0000 Organization: Armstrong Laboratory, Brooks AFB, TX Lines: 179 Sender: faq@hrd769.brooks.af.mil Approved: news-answers-request@MIT.Edu Distribution: world Expires: 12/31/93 Message-ID: <386bsd-faq-8-755762418@hrd769.brooks.af.mil> References: <386bsd-faq-1-755762418@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/part8 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 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.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.