Return to BSD News archive
Xref: sserve comp.os.386bsd.announce:489 comp.answers:7505 news.answers:29561 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!ihnp4.ucsd.edu!agate!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!solaris.cc.vt.edu!insosf1.infonet.net!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-782024410@cynjut.infonet.net> Followup-To: comp.os.386bsd.misc Date: 26 Oct 1994 22:59:04 -0500 Organization: Dave's House in Omaha Lines: 425 Sender: burgess@s069.infonet.net Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu Distribution: world Expires: 11/13/94 21:52:32 CDT Message-ID: <386bsd-faq-8-783229952@cynjut.infonet.net> References: <386bsd-faq-1-783229952@cynjut.infonet.net> Reply-To: burgess@cynjut.infonet.net (386bsd FAQ Maintainer) NNTP-Posting-Host: s069.infonet.net Keywords: FAQ 386bsd NetBSD FreeBSD !Linux 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: tty00:dv=/dev/tty00:br#9600: tty01:dv=/dev/tty01: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/tty00 chown uucp.dialer /dev/tty01 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" = tty00, and "DOS Com2" = tty01. So, if your modem is at 0x2F8/IRQ=3 and you access it as the COM2: port from DOS, you would do.. tip tty01 To exit, type <RETURN>~.<RETURN> Many people have other problems with cu. The lock open: procedure is one of them. 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. If you receive the error "cu: write: Input/output error" You may be able to fix this by creating an /etc/uucp/ports file (see Taylor UUCP docs). In addition, those of you using cu version 1.04 may need to add the following to their susyem: create an /etc/uucp/ports file that looked like this: port mymodem type modem device /dev/tty01 speed 19200 Now cu knows that the line is connected to a modem it does the right thing regarding setting CLOCAL on the line. You don't even have to have either of local or softcar set in /etc/ttys. Since cu's behaviour seems to be correct, I'm happy now. All I need to really make my day though is to have John or Martin to tell me that cu 1.04 still works for them even though they don't have an /etc/uucp/ports (or equivelent HDB or V2 uucp config) file ... :-) 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.4.3 My modem on DOS COM3 or DOS COM4 works with DOS, but not with *BSD. It is set up using IRQ 4 (or 3) respectively. One of the MAJOR differences between DOS and *BSD is that *BSD actually USES the IRQ lines (*gasp*)... That means that every device on the ISA bus has to have it's own IRQ. Since COM1 and COM2 (/dev/tty00 and /dev/tty01) are already defined using IRQs 4 and 3 respectively, that means that COM3 and COM4 (/dev/tty02 and /dev/tty03) need to be put onto different IRQs. The default GENERICAHA kernel defines the third com port (COM3 or /dev/tty02) to be on IRQ5. You need to reconfigure your com port (for external modems) or modem (for internal modems) to use IRQ5. The GENERICBBT kernel defines the COM4 port to be on IRQ9 (or 2). If you have to put your devices on other ports, you will need to recompile the kernel. 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 My network manager (or UUCP feed site admin) just informed me that the way I have installed sendmail through my UUCP connection and has caused a sendmail loop. Can you help me get sendmail installed correctly? (1) Go into sendmail's source directory tree cd /usr/src/usr.sbin/sendmail/cf/cf (2) Make the missing obj directory first, you need it later... mkdir obj (3) Create a sendmail master configuration file (.mc file). Name it yourname.mc vi yourname.mc (4) Contents of the yourname.mc file: #--------------------------------------------------------------- divert(-1) # # This is the prototype for a site with only a uucp connection # to the world, where smarthost and uucp relay are the same ... # Replace "yourname" with your machines nodename without domain # Replace "smarthost" with your uucp neighbours nodename without # domain i.e. here is myname "knobel" and my smarthost is "gomel", # to which I'm connected with uucp via dialup modem. divert(-1) VERSIONID(`yourname.mc 1.0') include(`../m4/cf.m4') OSTYPE(bsd4.4) FEATURE(nodns)dnl MAILER(local)dnl MAILER(smtp)dnl MAILER(uucp)dnl define(`UUCP_MAX_SIZE', 2000000)dnl define(`SMART_HOST', `uucp-dom:smarthost')dnl define(`UUCP_RELAY', `uucp-dom:smarthost')dnl #-------------------------------------------------------------- In the siteconfig directory (.../sendmail/cf/siteconfig) create a file uucp.yourname Put a list of machines into this file to which you have active uucp/mail connection. Generally only the name of your smarthost .... Unknown addresses are routed to your smarthost .... siteconfig/uucp.yourname: #---------------------------------------------------------------------- SITE(nodename_of_your_smarthost) #---------------------------------------------------------------------- (5) create the new sendmail configuration file, which will be stored under obj/yourname.cf, by typing make yourname.cf (6) After that copy obj/yourname.cf to /etc/sendmail.cf (7) It's up to you to browse through the systems global aliases file ((etc/aliases), where important mail aliases are stored. After editing this file you should invoke the command newaliases to update the corresponding database file newaliases (8) Then create/edit the file "/etc/sendmail.cw". This file contains alias names of your system (a list of additional names under that your system might receive e-mail): yourname yourname.uucp yourname.domain (9) Then create a file /etc/mailertable: Here you have to say what else (uucp adresses, too) has to be sent to your smarthost ... .uucp uucp-uudom:name_of_your_uucp_smarthost (10) Create the hash table the following way: makemap hash /etc/mailertable.db < /etc/mailertable Remember, if you make any changes you have to rebuild the alaises database by typing: newaliases (11) BTW: You do not need to create a frozen config file, since sendmail on FreeBSD 1.X and NetBSD aren't compiled with that option turned on. (12) ``Hot files'' with more information (see sendmail src tree): FAQ KNOWNBUGS RELEASE_NOTES cf/README 7.7 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...