home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / answers / 386bsd-faq / part8 < prev    next >
Internet Message Format  |  1993-12-26  |  8KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!usc.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
  2. From: burgess@hrd769.brooks.af.mil (Dave Burgess)
  3. Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
  4. Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 8 of 10)
  5. Followup-To: comp.os.386bsd.misc
  6. Date: 27 Dec 1993 06:00:45 -0000
  7. Organization: Armstrong Laboratory, Brooks AFB, TX
  8. Lines: 205
  9. Approved: news-answers-request@MIT.Edu
  10. Distribution: world
  11. Expires: 01/14/94
  12. Message-ID: <386bsd-faq-8-756972021@hrd769.brooks.af.mil>
  13. References: <386bsd-faq-1-756972021@hrd769.brooks.af.mil>
  14. Reply-To: 386bsd-faq@hrd769.brooks.af.mil (386bsd FAQ Maintainer)
  15. NNTP-Posting-Host: hrd769.brooks.af.mil
  16. Xref: senator-bedfellow.mit.edu comp.os.386bsd.announce:215 comp.answers:3173 news.answers:16212
  17.  
  18. Posted-By: auto-faq 2.4
  19. Archive-name: 386bsd-faq/part8
  20.  
  21. Section 7.    (System Communication and Network Information)
  22.  
  23. 7.0    Communications
  24.  
  25.     386bsd and its kith support a wide range of communications methods.
  26.     
  27. 7.1    SLIP
  28.  
  29.     Serial Line I/P is supported in all versions of Net/2 derived BSD.
  30.  
  31.     Brian <brian@awfulhak.demon.co.uk> provides us with a rather
  32.     good explanation of some of the hurdles that must be overcome
  33.     for a working slip interface.
  34.  
  35.     The idea is (overview) that you make a serial line connection to 
  36.     the host, set the line discipline, and tell your router to use 
  37.     this interface as your gateway.  You also should set the gateway 
  38.     up as a nameserver.
  39.  
  40.     Sounds easy ? - well it is if you've done it before.
  41.  
  42.     The _usual_ way of doing this is as follows:
  43.  
  44.     Both server and client must know eachothers inet addresses.  Set 
  45.     these up in /etc/hosts with lines saying
  46.         11.22.33.44 host.my.domain.name host
  47.         11.22.33.55 client.my.domain.name client
  48.  
  49.     where 11.22.33.?? is your inet number, and the following name is 
  50.     the full machine name (and is followed by any number of aliases).
  51.  
  52.     SERVER:
  53.        Create a login - usually Sclientname - and run `sliplogin` as 
  54.        its shell.  I've looked at the docs for sliplogin, and it seems
  55.        fairly straightforward.  I haven't actually set up a server.
  56.  
  57.     CLIENT:
  58.       Set up /etc/resolv.conf to say the following (for the nameserver)
  59.         domain client.my.domain.name
  60.         nameserver 11.22.33.55
  61.  
  62.       ** traditional method **
  63.       - Log on to the server.  This is usually done via kermit or some
  64.       such program.
  65.       - Exit the program (or backround it if your line wants to drop 
  66.       once the device is closed).
  67.       - Run `slattach /dev/comport` for whatever "comport" is.  On most
  68.         Net/2 derived systems, this may be either com0, or cua01, or
  69.         whatever the correct name is for your site.
  70.       - Run `ifconfig inet sl0 clientname servername netmask 0xffffff00`
  71.       - Run `route add default servername`.
  72.       
  73.         "servername" is your server and "clientname" is your client.
  74.         
  75.       It should now be possible to `ping host`
  76.  
  77.     ** my method **
  78.       Configure /etc/remote
  79.       Configure /etc/host.dial
  80.       Run `slip host`.
  81.  
  82.     /etc/remote contains an extended `tip` entry.  /etc/host.dial 
  83.     contains a login script (and is named in /etc/remote).
  84.  
  85.     Oh yes, don't forget to have a line in your kernel config saying
  86.  
  87.     pseudo-device sl 2
  88.  
  89.     Without this line, you may get a 'device not configured' or 
  90.     'TIO...' error because the slip driver is not built into the 
  91.     kernel.
  92.  
  93.     I uploaded the slip package a while ago (to several archives), but 
  94.     was unaware of needing to notify the postmaster.  They've probably 
  95.     all been removed now.  Slip packages are available from many FTP 
  96.     sites; use archie to find the site nearest you.
  97.  
  98.  
  99. 7.2    CSLIP
  100.  
  101.     SLIP is included in the NetBSD-0.9 stock kernel and in the source
  102.     tree.  It is also available in FreeBSD.
  103.  
  104.  
  105. 7.3    PPP
  106.  
  107.     Implementations of Point to Point Protocol are also available.  PPP
  108.     should be available in the next major release (0.9+) of NetBSDi and 
  109.     in the current release of FreeBSD.
  110.  
  111.  
  112. 7.4    TCP/IP
  113.  
  114.     TCP/IP is an integral part of Net/2 BSD.  There are at least five
  115.     different network card drivers.  TCP/IP is fully supported and is
  116.     available to all users of Net/2 derived BSD systems.  In fact,
  117.     many people believe that this area is one of the primary advantages
  118.     that Net/2 has over Linux.
  119.  
  120.  
  121. 7.5    UUCP
  122.  
  123.     There is an excellent document included in the UUCP directory
  124.     that describes in detail, what needs to be done to get a working
  125.     UUCP for Net/2 BSD systems.
  126.  
  127.     
  128. 7.5.1    TIP/CU
  129.  
  130.     First thing you need to do is...
  131.  
  132.         vi /etc/remote
  133.  
  134.     Then remove the two lines at the bottom of the file that mention 
  135.     com1, and com2.  Now add the following lines:
  136.  
  137.         com0:dv=/dev/com0:br#9600:
  138.         com1:dv=/dev/com1:br#9600:
  139.  
  140.     That tells tip/cu where to find your com ports.  Next you need 
  141.     to be logged in as root and do a:
  142.  
  143.         chown uucp.dialer /dev/com0
  144.         chown uucp.dialer /dev/com1
  145.         touch /var/log/aculog
  146.         chown uucp.dialer /var/log/aculog
  147.  
  148.     Make sure that, if you are running newsyslog, you change the 
  149.     owner.group entry in the newsyslog.conf file so that the file
  150.     ownership is maintained correctly.
  151.  
  152.     Then you should be all set, remember "DOS Com1" = com0, and 
  153.     "DOS Com2" = com1.  So, if your modem is at 0x2F8/IRQ=3 and you
  154.     access it as the COM2: port from DOS, you would do..
  155.  
  156.         tip com1
  157.  
  158.     To exit, type <RETURN>~.<RETURN>
  159.  
  160.     Many people have a problem with the lock open: procedure.   
  161.     If you receive the error:
  162.  
  163.     lock open: no such file or directory
  164.     all ports busy
  165.  
  166.     You need to create a directory: /var/spool/lock, owned by uucp.  If
  167.     this file already exists and is owned correctly, make sure that the
  168.     lock file in the directory is deleted.
  169.  
  170.     This answer thanks to (crt@tiamat.umd.umich.edu).
  171.  
  172.  
  173. 7.6    Terminals
  174.  
  175.     Since the target machine for most Net/2 machines is a 386 with 
  176.     no more than a couple of serial ports, most people do not bother 
  177.     with serial terminals.  For most problems, a quick perusal of the 
  178.     man pages for the ttys file and getty are enough to get them 
  179.     started.  Other than that, most terminal problems are limited to
  180.     peculiarities of particular terminals.
  181.  
  182.     One common problem that appears to crop up from time to time is
  183.     which wires need to be connected at each end of the cable.  Most
  184.     cables do not, in fact, pass through all lines.  If your terminal 
  185.     uses XON/XOFF (DC1/DC3) protocol, a cable of the appropriate 
  186.     twist, either straight through or null modem, can have as few as
  187.     three lines connecting the two devices.  Assuming DB-25 connections
  188.     at each end, the lines need to go from 2 to 3, 3 to 2, and 7 to 7.
  189.     These lines are Rx, Tx, and gnd.  Other lines that may or may not
  190.     be required include 4 and 5; and 6, 8, and 20.  Normally, these 
  191.     lines would be connected within the 'hood' of the cable to simulate
  192.     the functionality of the full blown cable.  While full support for
  193.     CTS/RTS is not available (yet), other support for the remainder
  194.     of these lines is available or is being worked on in all Net/2
  195.     derived systems.
  196.     
  197.  
  198. 7.7    Can network attached assets be used by/from NetBSD?
  199.  
  200.     Yes, they can, assuming the machine at the other end of the 
  201.     connections is reasonably cooperative.  The specifics are up to the
  202.     remote machine, but a couple of things that you can start looking
  203.     for that will help are provided below:
  204.  
  205.         -  Ask the system administrator of the machine in question
  206.            if it is OK for you to use whatever it is you need.  This
  207.            is more a matter of manners than a technical issue.
  208.  
  209.         -  For NFS mounted disk drives, make sure that you are not
  210.            prevented from using the assets by the /etc/exports
  211.            (or equivalent) file.  This goes for CD-ROMs as well as
  212.            regular mounted disks.
  213.  
  214.         -  There are a completely different set of concerns for
  215.            tapes and printers.  Each system implements these in
  216.            slightly different ways.  Check with your system manager
  217.            or documentation for more information.
  218. -- 
  219. TSgt Dave Burgess
  220. NCOIC Applications Programming Branch
  221. US Strategic Command, Offutt AFB, NE
  222. burgessd@j64.stratcom.af.mil
  223.