----------------------------------------------------------------------------- This is the LINUX NETWORKING FAQ by Phil Copeland (p_copela@csd.uwe.ac.uk). ----------------------------------------------------------------------------- Last revision: 17 Feb 1993 quick disclaimer: I must appologize for my luck of a spoll checkr 0. About this NET-FAQ This is the Linux Networking FAQ, which covers all of the details of setting up TCP/IP under Linux, either for a network or only for loopback mode. It's maintained by Phil Copeland, but this revision is by Matt Welsh (mdw@tc.cornell.edu). New versions of this doc will be posted to comp.os.linux.announce and can be found on the major Linux FTP sites such as sunsite.unc.edu and tsx-11.mit.edu. The version of the kernel used in this NET-FAQ is 0.99.5 and the GCC compiler is 2.3.2. Thus, some of these things may or may not work depending on your kernel and compiler setup. My personal setup is a 486dx-25, 8Mb mem, 105 Mb Scsi Disk, Adaptec 1542B Scsi Controller, Generic Scsi Tape (60Mb), 1200 Baud Hayes Modem (HP on com2), Inmos B004 transputer board (2Mb), Western Digital 8013 16Bit network card, 2 serial ports (com1/4), Single printer port and Paradise Pro Designer II SVGA card. This mountain of equipment co-exists happily with each other and works in harmony with each other. (I only include it here so that people realize that such setups can exist) 0.1. A Request If you find some text I've written which no longer applies or is a complete load of rubarb, please tell me and include a reason or corrective text (patch file/ context diff/ off the top of your head formats are very welcome) 0.2. Foreward This NET-FAQ has grown quite large (~70k) and the past few versions contained so much information and were downright confusing. So, we revamped it and added a "Quick Start Guide", a quick overview of setting up TCP/IP under Linux. It's really quite easy to get everything going. There is a lot of reference information here so don't be scared off. 1. Introduction Hello and welcome to the wonderful world of Linux networking. Networking has always been one of the most exciting things that you can coax a computer to take advantage of. It allows you to store/retrieve files from remote machines (some of which are probably located in countries which you'll never get to visit). Networking also allows computers to interactively communicate with other processes or users on these remote machines allowing a new social aspect of computing to be approached (mainly in the form of talk or MUD (Multi User Dungeon) sessions). Networking also has many stumbling blocks for the administrator to fall over, most notably the initial setting up of a system network which can send the most sane person to eating the proverbial hat through the hell of trying to coax their machines into networking life. This FAQ is designed to help you start into networking in a positive direction by leading you simply through the network configuration that best suits you, whether you have a single machine with no network attachment (silly I know) or a multi billion credit networking computer for your country's local stock exchange. Please note that this FAQ does not follow the 'normal' format of other FAQ's as it's designed to teach you networking and its idiosyncacies. As of 21 Jan 93 there is a Linux Networking Quickstart guide (in the next section) by Matt Welsh to help review the process of getting it all going. 1.1. Linux Networking Support The Linux kernel is now distributed with the TCP/IP code in it. Basically, Linux's network support is for either UNIX (local) domain sockets or INET (TCP/IP) domain. This FAQ specifically covers configuring TCP/IP for Linux. You can either configure it in "loopback mode" (which allows you to telnet, ftp, etc. only to your own machine) or, if you have an Ethernet card, for use on a network such as the Internet. 1.2. Supported Ethernet Cards To put your machine on a network you need an Ethernet connection of some kind and an Ethernet card in your machine. Linux supports a number of Ethernet cards, although only the WD8003 and WD8013 (aka SMC Elite) cards come with the standard kernel. Donald Becker wrote up the following information regarding Ethernet cards, prices, etc. The least expensive 8 bit ethercards start at $70 and are usually NE1000 clones. It's definitely worth it to pay an extra $10 and go for a 16 bit bus interface NE2000 clone. For another $10-$15 you can get a shared memory 8013 clone, which will give you somewhat higher system performance. You should expect to pay more than the price I listed above unless you do careful shopping from the back of Computer Shopper and (even better) LAN magazine. I've gotten network things from both MCW Distributors in Gaitherburg MD (good prices, sort of local, advertises in Comp.Shop.) and Network Express (a little more expensive). You'll also have to decide the kind of interface you need. "Thinnet" is RG58A 50ohm cable with BNC connectors. 10BaseT is twisted pair ("TP") to a central "hub". There is also traditional thick 50ohm cable, but it has no advantage in most installations. An "AUI" port is a 15 pin D-shell connector that can be hooked to an external transceiver (ca. $50 for 10BaseT or thinnet), usually for thicknet (in which case it's $100+). Cards typically have an AUI connector and either a thinnet or twisted pair transceiver. You'll pay about $20 more and give up the AUI to get both thinnet and 10BaseT. Some ethercards advertise status LED. These are most useful for 10BaseT connections, which are easy to mix up. IMHO, thinnet with on-card transceivers results in a _much_ cheaper system. You only need to buy T connectors($3ea.), cables ($6/12ft at RS), and two terminators ($2ea.), leading to a per-node cost of under $100. At these price levels it's definitely cheap enough to put on a home system! With twisted pair you'll need a hub which can easily double your per-node code. TP is only cost-effective if the wiring is already there and its expensive to run more. These drivers support all common 8390-based ethernet boards. Currently "common" is defined as: 2. What you need to get started To configure TCP/IP under Linux you need: 1) A linux machine with linux kernel 0.98.5 although I'd recommend going all the way to 0.99.5 as many tcp/ip errors have been stomped out (although not all). 2) Version 4.2 of the jump table library image (/lib/libc.so.4.2). This is needed for the various network binaries and so on. The most recent version is on sunsite.unc.edu:/pub/Linux/GCC. 2) If you're going to use TCP/IP over the network (i.e. not just loopback mode), then you need one of the following Ethernet cards: wd8013 wd8003 SMC Elite 16 ne2000 Alta Combo (ne2000 clone) Aritsoft LANtastic AE-2 (ne2000 clone w/ extra memory) D-Link Ethernet II ne1000 3Com 3c503 EtherlinkII 3Com 3c503/16 Cabletron E1010, E1010-x, E2010, E2010-x various HP 8390-based boards such as the HP27245, HP27247A, and HP27250 The wd8003, wd8013, and SMC Elite 16 are all included in the standard Linux kernel. The ne2000, ne1000, 3c503, Cabletron, HP, and and other 8390 card drivers are available for beta testing. This will be covered later. 3) If you are only going to use 'loopback' mode, you won't need a card! A special loopback device is used to communicate with yourself. *** NOTE when talking of ethernet devices, it should be noted that /dev/eth0 does NOT exist, the kernel knows about it and thats all you need to know, /dev/eth0 and /dev/loopback are fictionous (FS speaking) 4) The tcpip-0.8 networking package. This is the old, original release of the TCP/IP software. The only things you need from this package are the 'config' program and the network installation scripts (such as rc.net, install.net, and so on). Everything else in the tcpip-0.8 package (the kernel code, diffs, binaries, etc.) is obsolete. You also need the tcpip-0.8-fixes package. You need more or less everything from this package: the exact files you need are covered later. NOTE: If you have SLS you should have everything you need in /usr/etc/inet already. It's available from all of the major Linux FTP sites, in the file tcpip-0.8.tar.Z. The fixes are in tcpip-0.8-fixes.tar.Z. They should both be in the same place. 5) The net-bin-0.2 package. It's on sunsite and tsx-11 in the file net-bin-0.2.tar.Z. This file contains all of the TCP/IP clients and daemons that you'll need, including: telnet, telnetd, ftp, ftpd, inetd, named, rcp, rlogin, rsh, talk, ping, nslookup, and more. 6) You don't need the net-lib-1.1 package. The libraries have now been added to the most recent libc.so.4.2, so if you have that you're set. 7) If you want NFS support, Linux 0.99 now contains NFS as a of mount which lets you NFS mount a filesystem (i.e. mount a filesystem on another machine). Look on nic.funet.fi in /pub/OS/Linux/ALPHA/NFS. 8) Know the IRQ's of your internal cards. This is to avoid conflicts and allow the 'drivers' to communicate with your hardware 9) Also, If you do have ethernet cable, both coax (thin and thick) as well as twisted pair will work, the cable is only there to carry signals, your ethernet board works out how and the linux 'drivers' simply stuff data onto the card. 10) A lot of coffee and one of those stress relieving gadgets you can get in the local market. [Ed. note: I had about 3 Dr. Peppers and I was okay. -mdw] 3. Quick Start Guide to setting up Linux TCP/IP This is a rundown of what you need to do to setup TCP/IP. Read it through and then keep it all in mind as you're cleaning up all of the details below. It's not difficult if you do everything correctly. It's not as quick as I wanted it to be. Basically I get all of the installation stuff straight and then let Phil explain the details of setting up named, etc. later in the NET-FAQ. This section was written by Matt Welsh. - NOTE: In this discussion, the directory /usr/etc/inet is used to hold the tcp/ip daemons, configuration files, and so on. You can use ANY directory you want, as long as you're consistent. Two popular alternatives are /etc/inet or just /etc. I like to keep all of my tcp/ip stuff in /usr/etc/inet just to keep it seperate from my other /etc files (because I toy with it a lot). This is mostly personal taste. TCP/IP clients (such as telnet, ftp, and so on) can go anywhere on your user's path. The canonical place is /usr/bin. It doesn't really matter; here I install clients in /usr/bin. - (Another) NOTE: Some programs, like fingerd, expect certain files to be in certain places. For example, fingerd won't work if finger is not in /usr/bin. The easiest solution is to make a symbolic link if you put your clients, etc. elsewhere. If something doesn't seem to be working, make sure everything's in the right place and has correct permissions. One way to find out where a program expects companion programs or files to be is to use 'strings'. For example, strings fingerd | more will show you all of the printable strings in the fingerd binary; you can use this information to find out where fingerd expects finger to be, and so on. - First things first: Get all of the files, etc. listed above in section 2.0. When unpacking the tcpip-0.8, tcpip-0.8-fixes, and net-bin packages, it's helpful to unpack them in separate directories, because we'll be moving the files around to the right places. For example, unpack tcpip-0.8.tar.Z in /usr/src/tcpip-0.8 and net-bin-0.2.tar.Z in /usr/src/net-bin (or something like that). NOTE: The current version of SLS (0.99.2 and up) already have pretty much everything you need to get networking going. The configuration files all live in /etc/inet, with /usr/etc/inet being a logical link to this location. So if you have SLS you probably don't need to get all of these files. - Most of the files in tcpip-0.8 you don't need. After you've unpacked it somewhere, take inet.tar and unpack it in /usr/etc/inet (which you may need to create). You can delete the following files in /usr/etc/inet: config inetd named-xfer telnetd named (Don't worry; later we replace them with newer versions). - The rest of the files from tcpip-0.8.tar.Z you can delete. - Unpack tcpip-0.8-fixes.tar.Z in /usr/etc/inet. You can delete the file 'config' from it. - Take the config.c (from tcpip-0.8-fixes) and compile it in /usr/etc/inet with the command gcc -o config config.c NOTE: If you do not recompile config, you will probably get an ioctl error when you reboot with networking installed. To avoid problems, you should recompile the program with the above command. - Having unpacked net-bin-0.2.tar.Z in /usr/src somewhere, you can install these binaries. The following files are copied to /usr/bin: ftp telnet ping (must be setuid root; i.e. do 'chmod 4755 /usr/bin/ping') nslookup nsquery nstest rsh (must be setuid root) rcp (must be setuid root) rlogin (must be setuid root) finger talk tftp The following files are copied to /usr/etc/inet: ftpd telnetd inetd named named-xfer rshd rlogind fingerd ntalkd tftpd The man pages are copied to /usr/man... for example, all *.1 are copied to /usr/man/man1 and *.8 are copied to /usr/man/man8. - Now you've got all the software installed, you need to recompile your kernel with TCP/IP enabled. This is easy unless you have an old kernel (pre-0.99) or need to install the ne2000/3c503/ne1000 drivers. Here's how. IF you're installing the 8390/n2000/3c503/ne1000 drivers (from super.org, directory /pub/linux/newether), follow the directions below for installing the driver. If you're NOT installing the 8390 driver (or only want to use loopback), just skip down to compiling the kernel. Get the files that you need. See the README's there for full details. Basically you need: 8390.c 8390.h Space.c auto_irq.c GNUmakefile one or more of ne.c, wd.c, 3c503.c/3c503reg.h, and so on, depending on the card you have. Note that if you have 0.99.pl5 or above you need to get the 8390.c from /pub/linux/ether-995 instead (as a lot of kernel TCP/IP code changed/got better with 0.99.pl5). Just follow the directions found in the file INSTALL on super.org. It's easy. Just: - Put the files above in /usr/src/linux/net/tcp. - Edit the GNUmakefile to define which card you have, your base address, and your IRQ. Note that with these new drivers if EI8390 (the base address) and EI8390_IRQ (the IRQ) are defined to be 0, they will be automatically detected at bootup time. - Edit Space.c (if needed), - If you changed the GNUmakefile to use "eth_if" instead of "eth0" (note that the newest 8390 drivers use "eth0" like everyone else, they previously used "eth_if"), then you need to edit /usr/etc/inet/rc.net to run $CONFIG on "eth_if" instead of "eth0". If not you'll get an ioctl error from config. If you have problems with the 8390 driver, contact becker@super.org. - If you're NOT installing the 8390 driver (i.e. just using the wd8003 driver with the standard kernel), then you need to edit /usr/src/linux/net/tcp/Space.c to reflect your card's IRQ, base address, and so on. If you're only using loopback you can skip this step, too. Anyway for those who are flexible, the standard kernel parameters for this are : IRQ: 5 (card interrupt) mem: D0000 (where in memory to buffer data) i/o addr: 280 (low level address of card) mem start: D0000 (nearly all boards have a jumper to set this) mem end: D2000 (for wd8013, make this D4000) NOTE: If you have problems with the memory start addr for the WD80[0/1]3, please get in touch with bir7@leland.stanford.edu. - Now you're all set to compile the kernel. I really suggest that you use version 0.99.pl4 or newer (probably 1.0 by the time this is out). If you don't have at least 0.99 you can't run 'make config' to autoconfigure the kernel and you'll have to do some stuff by hand. In any case, it's easy. If you have 0.99 or newer, just cd to /usr/src/linux and do a 'make config'. Make sure you answer 'yes' to the question on configuring TCP/IP. The rest of the options are up to you. Also make sure you edit /usr/src/linux/Makefile to fix your root device, keyboard, and so on. Then do a 'make dep' to fix your dependencies--- THIS STEP IS VERY IMPORTANT. Then (if you've already compiled this version of the kernel) do a 'make clean'. FINALLY you're ready to just do 'make' to compile the kernel. When you're done you'll have the new kernel in /usr/src/linux/Image. Copy it to a floppy or install it in /etc for use with LILO, or whatever. Reboot with your new kernel. - Once you're rebooted you can configure the stuff in /usr/etc/inet. Run the script 'install.net' there, and answer the questions to set your IP address, net address, router, domain name, and nameserver. This is covered later in the NET-FAQ. NOTE: If you have SLS then the "install.net" file isn't used. Instead you need to edit hosts, resolv.conf, rc.net, and so on by hand to set up the various addresses. It's very straightforward; just make sure that the various configuration files (discussed below) in /etc/inet have the correct information. NOTE 2: If you're only using loopback, then your IP address is "127.0.0.1", and you don't have a router, network address, or net mask (these are things prompted for by install.net). For SLS, which doesn't have install.net, you just edit the config files in /etc/inet to reflect this. - I had to edit resolv.conf there to make sure that the hostname and domain names were right. No big deal. Under SLS you need to set your hostname in the file /etc/inet/host (not 'hosts') and set the domain name in /etc/inet/domain in addition to this step. - Set up your named configuration files. Named is the service that allows your machine to act as a nameserver. If you have a real nameserver already, you probably don't want to run named (wastes memory). If you're on loopback, you don't need it either (just put all of your hostnames and ip addresses in /usr/etc/inet/hosts). Named is nice if you have a LAN setup and want your Linux box to be the name server. This is covered in detail later in the NET-FAQ as well. In general you don't need to run named unless you really like hacking with DNS. I don't see any need for it, since you can put all of your hostnames in /usr/etc/inet/hosts and/or consult another nameserver. - Create the file /usr/etc/inet/host.conf. This file tells the name-binding libraries how to look up names: in this case, we're going to tell the libraries to check first /usr/etc/inet/hosts and THEN ask the nameserver (if any). So, create /usr/etc/inet/host.conf. It should contain only these 2 lines: order hosts,bind multi This is VERY IMPORTANT. If you don't create this file then you probably won't be able to look up names as expected. - Set up inetd.conf to include lines for all of the tcp/ip daemons (such as telnetd, fingerd, etc.) that you have in /usr/etc/inet. This is covered later. - Make sure that /usr/etc/rc.net is run from your /etc/rc.local. - Edit rc.net to make sure it's getting your IP address right. As it stands now it tries to grep for it in /usr/etc/inet/hosts, and this doesn't always work. I just hardcode my IP address in rc.net since my IP address isn't going to change much. :) SLS also tries to look up your net and router address from /etc/inet/hosts. I just hardcode these in as well as I don't trust grep. FOR LOOPBACK ONLY: If you're only using loopback, then edit rc.net to make your IP address 127.0.0.1, and you can ignore the netowkr and router addresses. In rc.net, you should only be running the config commands for "loopback", and no others, so comment out the lines which run config on "eth0". If you're using the 8390 driver (see above) make sure you've changed 'eth0' to 'eth_if' on the config commands in rc.net. - If you're not running named, you can comment out the lines which start it in rc.net. This will save memory and CPU time. - If you're not going to run NFS, you can comment out the lines in rc.net which run nfsd, mountd, portmapper, and routed. - If you want to use NFS (network file system), you're on your own. It should suffice to say that you need the nfs-client stuff from tsx-11 and nfs enabled in your kernel. Should be easy, I haven't played with it yet. - If you didn't already, read all of the README files that come with net-bin-0.2 and all that. They contain more up-to-date info. NOTE that the info in tcpip-0.8's README file is mostly out-of-date, follow the directions above and you'll be okay. - At this point you should be able to reboot your system, rc.net will run, and you'll see something like loomer -> 128.253.153.53 Starting /usr/etc/inet/inetd which is output from rc.net. If you don't see this (or if there are errors) then there's a problem; the best way to fix this is to edit rc.net and the other files in /usr/etc/inet and make sure you have your IP addresses and everything set right. Okay, that's about it for this so-called "Quick Start" guide. the rest of the NET-FAQ will fill in the gaps and talk more about networking than how to install the softs and configure the kernel. 4. Running install.net As mentioned above, to set the various network numbers, etc. for your system you need to run the install.net script, which sets lots of things in /usr/etc/inetd (mostly in hosts, resolv.conf, and so on). NOTE: If you're running SLS you don't have the install.net script. Just edit the files discussed in sections 5 and 6 of this net-faq by hand, it's not very difficult. All install.net does is put default values in these files for you. NOTE: If you're only on loopback, the only IP address you should be using is '127.0.0.1' which stands for loopback. You will be your own nameserver (either running named or just using /usr/etc/inet/hosts), and you don't need to worry about the router and subnetwork addresses. When running install.net you'll have to answer these questions: Enter IP Address for (your host) (aaa.bbb.ccc.ddd) Here you are being asked what network address you would like to be known as. Ip address are unique numbers so as to identify your machine from another on a multiuser network. Normally if you reside in the Internet you will have a network address assigned by the NIC or your local network controller and you really must stick to it since there is no room for you to bugger up the network by using someone elses ip address. If you do not have a connection to the Internet, you will have less of a problem although it would still be a good idea to apply for a internet class c/d network number depending on your setup. There is a convention being used that allows people who are completely bemused by all the ip registration stuff that allocates a band of ip numbers (192.0.2.xxx) which are encouraged to be safely ignored by the rest of the internet. So if you don't know what ip you'll be assigned or (naughty) can't be bothered, please use that range to avoid bringing sections of the internet around your ears. IP numbers are typically of the 0-255.0-255.0-255.0-255 range so valid answers are 243.123.4.23 or 192.35.173.3, etc. 324.234.545.2 is completely wrong. Enter Net Address for (your hostname) (aaa.bbb.ccc.0) Here you are being asked for your subnetwork address. This requires a bit of explaination. Subnets are a "unit" of connectivity which depict how many possible hosts 'live' on the same piece of cable as you do (typically this never exceeds 253 on one piece on cable) a quick way of getting the question right is to type in whatever you have for your ip address but make the last number 0 eg if my ip address were 135.56.33.155, my 'safe' Net address would be 135.56.33.0. 0.0.0.0 means the whole world and is probably what slip people should use. Enter Router Address for (your hostname) (aaa.bbb.ccc.ddd) Wibble! Ok here what is being asked is if you have a gateway machine through which IP traffic can be passed to the great blue yonder. We are sneekily getting the routeing machine to do some hard work for us. Routers tend to have 2 ethernet boards in them with differing network numbers for them so that they can 'bridge' between different numbered networks, eg you could not talk directly to a ip address of 192.35.173.12 from an ip address of 192.35.175.15 but a machine in the middle with two ip address 192.35.173.4 and 192.35.175.3 can 'collect' the data from the 192.35.173.xxx network and transfer it to the 192.35.175.xxx network. All we have to do here is stick in the ip address of the local router. You need to find this out from your local network admin types. If you don't have a router use 0.0.0.0 meaning don't route anything. Enter Domain name for (your host) This isn't too bad, domain names are 'convenient' labels eg uwe.ac.uk is the domain name that appends to all the machines on site so that a sun called csd would be known as csd.uwe.ac.uk This is so that you don't have to know the full ip number of the host, it's more convenient to call out a semi inteligable name eg 192.35.175.1 = csd.uwe.ac.uk but the 192.35.175 is aliased to uwe.ac.uk (University in the West of England, academic community, United Kingdom). Again this should be given to you with a registered ip address but for now you could put in 'at.linux.net' it can be changed later. mdw: In short the domain name is the name of your ENTIRE domain. For instance, my machine is loomer.ithaca.ny.us. The full hostname of the machine is 'loomer.ithaca.ny.us', and the DOMAIN name is just 'ithaca.ny.us'. Here you're being asked for the DOMAIN name only. Name Server for Domain (aaa.bbb.ccc.ddd) If you're on a University or business network, you'll probably have a nameserver. A name server just looks up machine names for you. For example, if you want to telnet to 'shoop.vpizza.com', you don't have to tell your machine what shoop.vpizza.com's IP address is; your machine can ask the nameserver instead. Ask your local network people what the nameserver for your network is. Here you're being asked for the IP address (number) of the machine, not the name. If you don't have a nameserver, then just put in your own IP address, and you can either run named or go without a nameserver (putting all of your names/IP addrs in /usr/etc/inet/hosts). 5. Other /usr/etc/inet configuration files Ok time for a quick check of what you minimally *SHOULD* have in /usr/etc/inet: config - This sets up the ethernet ip tables. inetd - Daemon process that invokes other network daemons inetd.conf - Configuration file for inetd about the other daemons install.net - The semi automatic script I just talked about named-xfer - Used for updating the nameserver records named.reload - used to load in the named named.restart - user to stop and restart the named process rc.net - a network rc file called from /etc/rc.local services - a file specifying what 'port' numbers certain services are available on telnetd - daemon for accpting incoming telnet requests named - the nameservice daemon Other daemons, such as fingerd, tftpd, and so on. Time for some explainations I think... 5.1 config 'config' is a general do it all 'fix your ethernet board to your local setup' command. It was configured when you ran the install.net script and if you look at the rc.net file you'll see where it plugged in all the IP stuff that you fed the script with... a bit technical but otherwise nothing to worry too much about provided that your original information was correct. One thing though, I have found that it is best to edit the rc.net file and 'hard wire' the ip addresses directly in rather than relying on the grep search from /etc/hosts but you may disagree (personal preferance). 5.2 host.conf You'll have to create this file yourself if you don't have it. With the new net-libs being made available by Mitch, you will find that it is possible to set up how ip addresses are looked up using the file /usr/etc/inet/host.conf with the entries: order hosts,bind multi which tells it in what order it should attempt to resolve an IP/domain name. In this case, when trying to match hostnames & ip addresses, the name binding libraries will search /etc/hosts and if no match is found then query the nameserver). If you run named then this is moot; you're your own nameserver. See below about named. 5.3 inetd 'inetd' is a daemon process that wait's for certain events to happen upon which it will select which process to run eg if no network communication is happening, only inetd will be running but if a telnet session is requested by a remote machine, inetd will start running telnetd for that incoming call to connect to. 5.4 inetd.conf Of much more interest is 'inetd.conf' which has information about what services to run and where to find them. Here's an example: # Serv type packet wait/nowait run as program to run invoke as # telnet stream tcp nowait root /usr/etc/inet/telnetd telnetd talk dgram udp wait root /usr/etc/inet/ntalkd talkd echo dgram tcp nowait root internal ftp stream tcp nowait root /usr/etc/inet/ftpd ftpd -l The net-bin-0.2 README file has a list of entries which you may add to inetd.conf. NOTE that inetd.conf cannot have any blank lines in it. This is a bug which will be fixed soon. Also, don't start services you don't need or don't understand, like tftpd. They will only waste resources and may have security implications. 5.5 protocols Now another file that comes to mind at this stage is /etc/protocols or rather /usr/etc/inet/protocols (I've made the symlink /etc/protocols -> /usr/etc/inet/protocols) This file contain's information on what protocol is to be used when the datagram packet arrives ie how it is to be treated. Here's an example /usr/etc/inet/protocols file: # protocols - standard well defined IP protocols ip 0 # internet protcol, pseudo protocol number icmp 1 # internet control message protocol igmp 2 # internet group multicast protocol ggp 3 # gateway -> gateway protocol tcp 6 # transmission control protocol egp 8 pup 12 # PARC universal packet protocol udp 17 # user datagram protocol idp 22 raw 255 # raw There are others but these are normally never needed. (NOTE: the /etc/protocols from the tcpip-0.8 distribution defines ggp to be 2 which isn't the case) If this file is missing or empty, you will never get any transports (ftp/telnet) to work and will be told that there isn't any such protocol. 5.6 services 'services' is a file which informs the tcp/ip code what port number a particular program will run on for example if you telnetted to port 7 on a sun you would be connected to an echo service which would send back a carbon copy of what you typed in but that service has a specially allocated port number referenced in the /etc/services file of both machines. There is a complete standardized services file in circulation from Ross Biro; it is included in the tcpip-0.8-fixes.tar.Z package. Ross: This is the one I made from the relevant rfc. It has some typos and such here, but it is probably ok for most use. Here's a *small* excerpt (not the entire file): # /usr/etc/inet/services tcpmux 1/tcp # TCP Port Service Multiplexer echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/udp users systat 11/tcp users daytime 13/udp daytime 13/tcp daytime 13/udp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail #Simple Mail Transfer time 37/udp timserver time 37/tcp timerserver # time name 42/tcp nameserver name 42/udp nameserver whois 43/udp nicname whois 43/tcp nicname nameserver 53/tcp domain nameserver 53/udp domain The other files in /usr/etc/inet are described in the named section below. 6. Names and name servers, what /etc/hosts is all about. The internet protocol document defines names, addresses and routes as follows: A name indicates what we seek. An address indicates where it is. A route indicates how to get there. Every network interface attached to a tcp/ip network is identified by a unique 32-bit IP address. A name (hostname) can be assigned to any device that has an IP address. Names are assigned to devices because, compared to numeric Internet addresses, names are easier to remember and type correctly. In use, most of the tcp/ip software on linux can interchangeably use name or ip address but whichever is chosen, it is always the IP address that is used to make connections. Translating names into addressses isn't simply a "local" issue. The command 'telnet fred.at.linux.net' is expected to work correctly on every host that is connected to the network. If the machine is connected to the Internet, hosts all over the world should be able to translate the name into a valid IP address, therefore, some facility must exist on the net to translate the name into the numeric IP address. There are two methods for doing this: one involves using a local lookup table ('/usr/etc/inet/hosts') and the other uses DNS (Domain Name System) to remotely interrogate the network for the IP address. 6.1 hosts '/usr/etc/inet/hosts' (or /etc/hosts) is a very simple file which contains a numeric IP address followed by one or more hostname aliases: # /usr/etc/hosts example # note that the hash is a comment, no text is processed after # it until the next # 123.45.67.20 csd csdsun csd.uwe.ac.uk csdsun.ac.uk 123.45.67.21 manic manic.uwe.ac.uk # Tom's machine 123.45.67.22 chef chef.uwe.ac.uk # Main waste of money # other nets 192.35.173.1 hal hal-9000 # local hidden host 192.35.173.2 slave slave.uwe.ac.uk # linux engine 485 25 192.35.173.30 zen zen.uwe.ac.uk # Interactive 2.2.1 386 33 192.35.173.35 thing # external nets 162.34.32.22 weird.emer.cty.oz Clearly this has a limitation in that on large networks ALL machines would have to have this information on disk and that could have 1000's of entries. Just think what that means if an extra 120 machines were added! 1000's of machines would have to have their /etc/hosts table updated either by hand or automatic shell scripts calling the list from a main machine... (see where this is leading?) Enter the DNS service... The SLS /etc/inet/hosts file is more involved, it specifies the router, network, and IP addresses. It's pretty self-explanatory but you should edit this file (because most everything's set here, as install.net isn't used with SLS). 6.2 DNS: Domain Name Service DNS scales well. It doesn't rely on a single large table; it is a distributed database system that doesn't bog down as the database grows. DNS currently provides information on approximately 700,000 hosts. DNS also guarentees thst the new host information will be disseminated to the rest of the network as it is needed. 6.2.1 named: running DNS from your own machine If you don't have a nameserver (which services DNS requests for you), and aren't just using loopback, then you can run named on your own machine. Named will allow you to setup a subsection of the DNS database for use on your own machine and local network. There are a number of files to be edited. These are: /usr/etc/inet/resolv.conf /usr/etc/inet/named.boot /usr/etc/inet/a_hosts_table (can be called anything, usu. just named.hosts) If you have a nameserver, the only file you need is resolv.conf, where you define your domain name and nameserver's IP address. These are both set up by install.net. For example: resolv.conf: domain uwe.ac.uk nameserver 192.35.173.21 However, if you're going to run named you need to define the 'nameserver' in resolv.conf to be YOUR OWN IP address. And you need to provide information in named.boot and a_hosts_table.... resolv.conf: domain uwe.ac.uk nameserver 192.35.173.2 named.boot: domain uwe.ac.uk primary uwe.ac.uk /usr/etc/inet/a_hosts_table a_hosts_table: @ IN SOA slave.uwe.ac.uk. root ( 1.1 ;serial 3600 ;refresh every 10 hours 300 ;retry every 6 minutes 36000000;expire after 1000 hours 3600 ) ; default ttl is 100 hours IN NS slave.uwe.ac.uk. slave IN A 192.35.173.2 hal IN A 192.35.173.1 zen IN A 192.35.173.30 . . . mother IN A 192.35.173.69 If you're going to run named, resolv.conf, named.boot, and a_hosts_table will suffice, BUT there are more (for other fun named options, etc.) 6.2.2 More complete list of named setup files YOU DON'T NEED to run named if you're only using loopback OR if you have a nameserver. It's a waste of CPU time and memory. But if you don't have a nameserver or if you just feel like hacking it, here's a more complete named setup: resolv.conf: If this file exists, it is read each time a process using the resolver starts. As a result, the file is not normally created unless necessary and isn't used if named is running. You should have it anyway in case named dies. :) named.boot: Sets general named parameters and points to the sources of the domain database information used by this server. The sources can be local disks or remote servers. named.ca: Points to the root domain servers named.local: Used to locally resolve the loopback address named.hosts: The zone info file that maps host names to IP addresses named.rev: the zone file for the reverse domain that maps IP addresses to host names (you'll prob never touch it so i'm going to skip it's description unless people get upset enough to lynch me) 6.2.2.1 hostcvt *** STOP PRESS *** I've just found out from Ross by sheer accident that there is a program released in comp.sources.unix (volume25) called hostcvt (mutter mutter) which is supposidly capable of converting /etc/host entries into the nesessary corrisponding named files. This program is now available on sunsite.unc.edu for Linux, in /pub/Linux/system/network. It's also distributed on SLS. *** RESUME PRESS *** 6.2.3 Where DNS gets its information The 'named.boot' file points to sources of DNS information. Some of these sources are local files; others are remote servers. You only need to create the files referenced in the primary and the cache statements. DNS commands | functions ----------------+-------------------------------------------------------------- directory | Defines a directory for all subsequent file referances primary | Declares this server as primary for the specified zone secondary | Declares this server as secondary for the specified zone cache | Points to the cache file forwarders | Lists servers to which queries are forwarded slave | Forces the server to only use the Forwarders ----------------^-------------------------------------------------------------- Here are some example setups of the named files. 6.2.4 resolv.conf domain uwe.ac.uk nameserver 192.35.173.2 As mentioned before, if you are going to be using named, this file is usually disguarded. Otherwise it points to a server that the resolver is to query for domain information. If no nameserver entries are contained in the file, the local host is queried for the information. 6.2.5 named.boot: ; cache only server ; primary 0.0.127.IN-ADDR.ARPA /usr/etc/inet/named.local cache . /usr/etc/inet/named.ca The loopback domain is an in-addr.arpa domain that maps the address 127.0.0.1 to the name localhost. The idea of resolving your own loopback address makes sense to most people, so most named.boot files contain this entry. 6.2.6 named.boot: ; Primary name server boot ; directory /usr/etc/inet primary big.cty.com named.hosts primary 54.152.IN-ADDR.ARPA named.rev primary 0.0.127.IN-ADDR-ARPA named.local cache . named.ca The directory statement tells named that all subsequent filenames are relative to the /usr/etc/inet directory. The first primary statement declares that this is the primary server for the big.cty.com domain and that the data for that domain is loaded from the file named.hosts. The second primary statement points to the file that maps IP addresses from 152.54.xxx.xxx to hostnames. This statement says that the local server is the primary server for the reverse domain 54.152.in-addr.arpa and that the data for the domain can be loaded from the file named.rev. 6.2.7 DNS Resource Records (RR's) Resource Records are used in the named files to set attributes of addresses, networks, and so on. Here's a list of the RR types: Resource Record Record type function ----------------------------------------------------------------------------- Start of authority SOA Mark the beginning of a zone's data, and define parameters that affect the entire zone Name server NS Identifies a domain's name server Address A Converts a host name to an address Pointer PT Converts an address to a hostname Mail Exchange MX Identifies where to deliver mail for a given domain name Canonical name CNAME Defines an alias host name Host information HINFO describes a hosts hardware and OS Well Known Service WKS Advertises network services ------------------------------------------------------------------------------ These resourse records are defined in RFC 1033. The format of DNS resourse records is: [name] [ttl] IN type data name: This is the name of the domain object the resource record references. It can be an individual host or an entire domain. ttl: time-to-live defines the length of time in seconds that the information in this resource record should be kept in the cache. Usually this field is left blank and the default ttl set in the SOA is used. IN: Identifies the record as an internet DNS resource record. There are other classes of records, but they are not used by the DNS type: Identifies what kind of resourse record this is data: the information specific to this type of resourse record 6.2.8 The cache Initialization file The basic 'named.ca' file contains "NS" records that name the root servers and "A" records tha provide the addresses of the root servers. A basic 'named.ca' is shown here: named.ca: ; named.ca - typical setup ; ; Servers for the root domain ; 99999999 IN NS tsx-11.mit.edu. 99999999 IN NS nic.funet.fi. ; ; Root servers by addresses ; tsx-11.mit.edu. 99999999 IN A 231.232.21.12 nic.funet.fi. 99999999 IN A 123.45.67.32 Note that the ttl is 99999999 the largest possible size so that the root servers are never removed from the cache. 6.2.9 The 'named.local' file The 'named.local' file is used to convert the address 127.0.0.1 (the loopback address) into the name localhost. It's the zone file for the reverse domain 0.0.127.in-addr.arpa. Because ALL systems use 127.0.0.1 as the loopback address, this file is virtually identical on every server. named.local: @ IN SOA slave.uwe.ac.uk. root. ( 1 ; serial number 36000 ; refresh every 10 hrs 3600 ; retry after 1 hr 3600000 ; expire after 1000 hrs 36000 ; default ttl is 10 hrs ) IN NS slave.uwe.ac.uk. 1 IN PTR localhost. 6.2.10 The 'named.hosts' file The 'named.hosts' file contains most of the domain information. This file converts host names to IP addresses, so "A" records predominate, but it also contains "MX", "CNAME" and other records. named.hosts: ; named.hosts file example ; @ IN SOA slave.uwe.ac.uk. probs. ( 1 ; serial 36000 ; refresh every X seconds 3600 ; retry every X seconds 3600000 ; expire after X seconds 36000 ; default time to live X seconds ) ; define nameservers and mailservers IN NS slave.uwe.ac.uk. IN MX csd.uwe.ac.uk. ; ; define localhost ; localhost IN A 127.0.0.1 ; ;hosts in this zone ; loghost IN A 192.35.173.1 hal IN A 192.35.173.1 zen IN A 192.35.173.30 thing IN A 192.35.173.35 slave IN A 192.35.173.2 IN MX 2 192.35.173.2 servant IN CNAME slave.uwe.ac.uk. mother IN A 192.35.173.69 ; ; outside domains now follow ; csd IN A 192.35.175.1 IN MX 5 192.35.175.1 csdsun IN CNAME csd.uwe.ac.uk. chef IN A 192.35.176.1 ; ;fictional outside gateway midway IN A 166.23.44.2 ; ; etc until you have built a reasonable host table ; that you feel will be adaquate for your network 7. NFS: The Network File System Network filing systems are convenient mechinisms which allow your machine axcess to more disk space that it actually has by 'borrowing' disk space from another networked machine for either sharing of common data or if allowed, the storing of data generated by your machine. NFS has several benefits: 1) it reduces local disk storage requirements because a network can store a single copy of a directory, while the directory continues to be fully accessible to everyone on the network. 2) NFS simplifies central support tasks, because files can be updated centrally, yet be available throughout the network. 3) NFS allows users to use familiar UNiX commands to manipulate files with rather than learning new ones. There is no need to use rcp/tftp/ftp to copy files, just 'cp' will do. As of 0.99.2 support has been added into the kernel for running binaries on both the MSDOS and NFS filesystems (of course the binaries have to be Linux type binaries to run on your system). Linus warns that they'll be slower to load and won't be memory effecient; there are hopes that this will change soon. Linux now has the following filesystems available for it: minix, extfs, msdos, proc, isofs, nfs with a view to a compressed filesystem being worked on (zfs?) all are perfectly transparent to each other although filename tructation may occur. The reason that I mention this is that NFS will allow you filename lengths supported by the type of filesystem you mount eg the HP9000 here supports 15 char filenames on an NFS mount as does it's MAG-OPT drive whereas the sun4's offer 255 char filename on their NFS exports. 7.1 The '/etc/exports' file If you want your machine to be an NFS server for other systems, you must run nfsd, mountd and edit /etc/exports. '/etc/exports' allows your machine to decide what local filesystems it will allow remote clients to NFS mount and decide what access those clients should have to your filespace. Example (I just love examples): / slave(root_quash) moonbeam(root_quash) /usr (ro,root_quash) /home slave csdsun --------v---------------------------------------------------------------------- flag | function --------+---------------------------------------------------------------------- ro | read only, this is the default rw | read and write, used to allow a client to write to that FS --------^---------------------------------------------------------------------- There are other options but these are covered in the README for the NFS kit and the above are the simplest to get to grips with. 7.2 The /usr/etc/inet/rc.net file The file 'rc.net' is used to start the named services and nfs the suggested setup is as follows: . . . if [ -f /etc/portmap ] then echo "Starting portmapper..." /etc/portmap if [ -f /etc/exports ] then echo "Starting nfsd..." /etc/nfsd echo "Starting mountd...." /etc/mountd fi echo mount -vt nfs fish:/pub /pub & mount -vt nfs sparky:/mnt/a /test & fi Here if the portmapper isn't running it is started. Once started, it is now possible to 'hang' the nfsd daemon as well as the mountd daemon off it. The two mount commands are from the modified mount command that come with the NFS package and both are run in the background so that if one of the servers were unreachable the system would continue to try while going on to finish the system setup and allow root/users to login. The '-vt nfs' bit isn't nessessary as the mount program understands the nfs syntax and mounts it as an nfs system but I include it anyway. 8. '...And on the 6th day she said, "let there be connectivity"...' All this is well and fine but shows nothing of how to use the various utilities commonly taken for granted in networking. ie telnet & ftp and X11. 8.1 telnet Normally people would telnet over a LAN (Large area network) to a remote site simply to play a mud (multi user dungeon) which runs on a socket say port number 4000 so the command 'telnet wopr.magic.mount.mil 4000' would connect to a service offered by that machine on port 4000. Now then, sockets are most easily perceived as 'openings' in a wall where data may pass through in a uni/bidirectional fashion, there are any number of ports available for use and quite a few reserved port sockets can be found in your /etc/services file. For example by telneting to port 7 of your target machine you should be able to communicate with the computer by typing in a few charcters and pressing return. Port 7 is the echo service and any input you type should be sent back exactly as you sent it. In normal use, however, telnet connects to port 23 where a login service is provided for interactive logins to the system. The canonical usage of telnet is just telnet where is another machine on the net that you want to log into. 8.2 ftp Ftp allows the user to transfer files from the host to the target machine but requires the user to login as (s)he would normally. Once logged in the user can transfer files both into and out of the machine with simple commands like 'get text.doc' or 'send report.wps'. Ofter ftp is used in the 'get' mode and when browsing sites it is usefull to know that you can peek at the contents of a small README file using the command 'get README.requirements /dev/tty' which will transfer the contents of the file to your tty line (in english: the screen) To start up FTP, just do ftp where is the machine you want to upload/download from. For public FTP service, login on the remote machine as "anonymous" and give your e-mail address as the password. 8.3 X11 and networking After you have networking set up, you can now run X Windows across the network. For example, you can login to a remote machine in one xterm, and from that machine run an X program and direct it to display on your machine. For example, if your Linux machine is called "shoop", on the remote machine the command xclock -display shoop:0 & would display the clock on shoop's display. Before you can do this, however, you must run the command "xhost" on shoop to allow the remote machine to display on shoop. If the remote machine is "loomer", from shoop you must run the command xhost loomer to give loomer this access. This is the entire concept underlying X Windows: you can now run huge programs (such as Mathematica) on remote machines and have them display on your Linux box. 9. Standalone named Configuration What follows is an example named configuration for a local (2-machine) isolated network. Well after some peer pressure, I see that I'm going to have to include a standalone configuration in the FAQ as well. According to my sources/hallucinations, there is an accepted address that is for 'junk' setups so as not to conflict with other machines on the internet. That address is 192.0.2.xxx where xxx ranges 0..255. (This address is not routed through the internet so you should be relatively safe from ip address clashes). I'm going to assume that your configurations will be held in /etc so the following files will be referanced there instead of /usr/etc/inet or /etc/inet. (NOTE: This deviates from the discussion above. /etc is fine to use instead of /usr/etc/inet as long as you're consistent). A while ago I posted a couple of messages concerning the setup of the named daemon config. files for a simple isolated network with a local nameserver. Since nobody responded with a ready-to-go solution I decided to dig a little deeper into the subject. As a result I've now got a working nameserver. This message describes the changes I made. Here goes: 9.1 General Info My isolated network consists of 2 machines, called whisky and jenever which are both located in the domain vdm. Whisky has IP address 192.0.2.1 and jenever has IP address 192.0.2.4. The nameserver runs on whisky, and jenever accesses whisky to resolve names. Starting point is SLS 0.98pl5. This distribution contains install.net and hostcvt, which are supposed to make network installation easier, but they where of no help to me. Instead, I manually changed the files concerned. 9.2 Common changes to files for both machines. /bin/hostname machine_name added to /etc/rc. Machine_name stands for either whisky or jenever. This command should be placed before the /bin/sh rc.local command. Further hostname commands removed from /etc/rc and /etc/rc.local. In /etc/inet/rc.net HOSTNAME=softland changed to HOSTNAME=machine_name. Commented out the IPADDR= line and inserted IPADDR=192.0.2.1 or IPADDR=192.0.2.4. ROUTER set to 0.0.0.0 and NET set to 192.0.2.0. In the third $CONFIG line eth0 changed into eth_if (I use an Artisoft network card, this isn't necessary for standard WD network cards). 9.3 Changes for the nameserver (whisky in my case). For a nameserver the portmap, inetd and named daemons should be started. This is done in the /etc/rc.net file. named.boot contains ----------------------------------------------------- directory /etc domain vdm primary vdm named.hosts primary 2.0.192.in-addr.arpa named.rev primary 0.0.127.in-addr.arpa named.local ----------------------------------------------------- named.hosts contains ----------------------------------------------------- @ IN SOA whisky.vdm. root.whisky.vdm. ( 1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 14400 ) ; Minimum IN NS whisky.vdm. localhost IN A 127.0.0.1 whisky IN A 192.0.2.1 jenever IN A 192.0.2.4 ----------------------------------------------------- named.rev contains ------------------------------------------------------ @ IN SOA whisky.vdm. root.whisky.vdm. ( 1 ; 3600 ; 300 ; 3600000 ; 3600 ) IN NS whisky.vdm. 1 IN PTR whisky.vdm. 4 IN PTR jenever.vdm. ------------------------------------------------------ named.local contains ---------------------------------------------------------- @ IN SOA whisky.vdm. root.whisky.vdm. ( 1; 36000; 3600; 3600000; 36000; ) IN NS whisky.vdm. 1 IN PTR localhost. ---------------------------------------------------------- 9.4 Changed for a non-nameserver (jenever in my case). For a non-nameserver only the portmap and inetd daemons have to be started. The startup of the named daemon in /etc/inet/rc.net can thus be commented out. A non-nameserver depends on a nameserver for name resolution. The non-nameserver is directed to a name- server by the /etc/resolv.conf file (NOT the /etc/resolv.conf as mentioned in a lot of doc. files). So, the /etc/inet/resolv.conf file on jenever contains: --------------------- domain vdm nameserver 192.0.2.1 --------------------- That's all. 10. Troubleshooting and Common Problems Here are some of the most common problems with Linux tcp/ip. 10.1 config One of the most common complaints regards the 'config' command. What isn't often noted is that this has to be recompiled from the 0.8.1 sources (available currently as tsx-11.mit.edu: /pub/linux/ALPHA/tcpip/tcpip-0.8.1.tar.Z). 10.2 Library versions Another problem that crops up is that some binaries that are distributed require libc.2.2.2 to be present (i.e. the telnet and ftp in tcpip-0.8. ONLY use the binaries in net-bin-0.2 or a newer version (which use jump-4.2 or newer) and you're okay. Other people think that it's their version of libraries that cause the problem but can't find the source code for the various utils to recompile. Get the net-src-0.2.tar.Z package from sunsite or tsx-11 and you're set; recompile at will. :) 10.3 kernel errors You boot the new kernel and suddenly all hell breaks loose... you have printk's telling you about RPC errors, framepacket errors etc... it looks a mess but the kernel keeps working... I suggest you grab HLU's bootdisk and edit your rc files again. Your problem here is most likely that you have accidentally attemped to use a working IP address as your own. If it's a sun's, you can expect the sun to lose all networking capabillity and not recover until lots of drastic commands are issued (fastboot won't help the guy either). I was asked to do this so I wasn't too fussed but loads os system admin people out there will get very ticked off if you do this deliberately. 10.4 named problems To check that something is working in named when it is run check out /usr/tmp/named_dumb.db. This is the file that named creates from all your configuration files. Check it exists, and contains formatted information similar to your named.hosts file. If it's zero length then something is wrong with your SOA record heading (A missing '.' perhaps). 10.5 More than one ethernet card in the machine, IRQ conflicts If you have more than one Ethernet card in your machine OR you have a device sharing the IRQ of your network card, you may have problems. Try pulling one of the cards and see what happens, or changing the IRQ (usually done with jumpers on the card). In the Linux kernel source, net/tcp/Space.c defines the network devices to configure. I hear that if you use the 8390/ne2000 driver on IRQ 5, the entry for the wd8003 card in Space.c will confuse things; thus just change the #ifdef around the wd entry in Space.c to something else so it's not compiled in. The following is provided by Ross Biro. If you get the message about time outs on the interrupt, you probably have your irq configured incorrectly. The irq in Space.c (default 5) MUST match the one on your card. If nothing happens when you try to use an interface, check the irq and try to get a new copy of config. Some versions fail to mark the interface as up (the config.c in tcpip-0.8-fixes should work). If you get messages about large packets and immpossible sizes to malloc, you have the memory on your card configured incorrectly, or there is a conflict with some other piece of hardware. Fix this by checking that your memory is configued right in Space.c and if it still fails, try ALL possible locations in memory (people have suggested that higher seems to work better.) If you get a message about runt packets, you can safely ignore it and/or comment the printk (kernel debugging output function) out of we.c. It indicates either a hardware problem or a initialization problem in we.c. It only seems to occur on some versions of the SMC Elite and there is other code to deal with the problem. Also Note if it works under DOS does NOT mean there is not a hardware problem. 10.6 General ideas Now then, to give you an idea of what is possible, I'll describe what I have setup and working. I have X11(Xfree86-1.2) running... In one xterm I have a dos session going, in another I have a telnet session connected to a sun (csd), and on that sun, i'm connected to a diku on the linux machine through 'telnet slave 4000', in yet another xterm I have an ftp session to yet another sun(chef) pulling CIA 10Megabugger world map onto an NFS mounted disk on another sun (hal) at a rate of about 35k/s (+/- 15k). I was going to mount up a swapfile on an NFS disk but decided against it on the grounds of what might happen if the external machine fell over while I was using that swapfile. Some relief can be found on the newsgroup/mailing lists but one thing that will *REALLY* help is this... #include #include #include char alpha_test[1..80]; FILE *panic; if ((kernel == lastest_on_offer) && (tcpip_broke)) { if (kernel_paniced) { fprintf(std_email,"give blurb about kernel\n"); system("nm ~linux/tools/system | grep "); listen(); } else { fprintf(std_email,"Conditions of error (recreatable)"); listen(); } } else { system(upgrade); system(try_again); exit(); } (Sorry about that, we had a compitition to find out who could write the whackist pseudo C code) more simply stated, the error address that is reported by the kernel can be used with a kernel system file to tell us what function broke and how far into it it broke. See below for more on that: Several things that can help 1) Upgrade your kernel to the latest one that you can grab (currently at time of writting 0.99.4). Alternatively if you are running 0.98.5, all the patches are available on sunsite.unc.edu:/pub/Linux/system/Network/tcpip, but as always, think strongly of going to a higher kernel version as they nearly alwas have all the patches applied for tcpip and other misc stuff. 2) Join the NET mail channel, you can learn an awful lot from the guys on this channel (like the various new copyrighted techniques for tearing out your hair) 3) Try and upgrade your C compiler and libraries to at least version 2.3.3 if possible. 4) Binary distributions of various network probrams can be found on sunsite.unc.edu,.. always read the README files they are there for a reason! (personal show/contacts/etc..) nic.funet.fi and txs-11.mit.edu also have good variation in utilities that you can use. Also don't forget that a lot of network programs will compile reasonably well although, be prepared for unexpected weeks of fustration. 5) Depending on your type of problem, contacting the author of the software or the person who ported the software would be a better choice. 6) If you are experiencing problems with missing files which are placed where you think they *should* be, it's always worth trying the following to find out what files are being used strings | less This should show up any hard linked files in the binary. eg differing versions of telnet will look at /etc/services OR /usr/etc/inet/services, therefore, it is a good idea to have a symlink from one to the other eg ln -s /etc/services /usr/etc/inet/services 7) If the kernel panics, jot down the address next to EIP. Then do an 'nm /usr/src/linux/tools/system | sort -n' and find out what function the given EIP address is in. This will help a lot. If you simply post the panic message to the newsgroup, everyone's kernel is different so it doesn't tell us much. 7) Complain bitterly to me if I haven't covered your problem and I'll get it sorted for the next NET-FAQ. 11. Cast of this production Ross Biro - Without whom all this wouldn't be possible and who pointed out holes in my documentation. Also contributed the history of tcp/ip on linux after he saw my rather perverted view of it. Mitch DeSouza - Constant alpha tester. Also pointed out mistakes and made critical and helpfull suggestions (like getting a spell checker). Also gave me his Tel No. which I used to annoy him with. Rick Sladkey - The current author of the NFS client code in the kernel. He also ported the NFS server and the RPC library. Donald Becker - Author of the drop in drivers for the linux kernel allowing the following cards to be used, 3com503, 3com503/16, NE2000, NE1000 and even a 3com501 (Donald: 'not recommended'). Matt Welsh - Trashed, er... reformatted this document, tried to clean it up. Wrote the tcp/ip quick start guide and answers tcp/ip config questions. The pioneers - These are the fearless people who brazenly marched their filesystems towards complete oblivion and watched weeks of work evapourate in milliseconds without a shred of hate for the OS that they had come to love. The supporting - You know who you are (probably, depending on how extras much virtual beer you had last night) for contributing to the network code with the various bug reports that inevitably crop up. Linus Torvalds - The elusive ecentric UNiX kernel coder who probably burns more CPU time on compiling than anyone else Here's to a long and healthy kernel development program and a Nobel equiv award for his efforts. The critics - For reminding me that it's a thursday... I never could get the hang of thursday's... Myself (Phil) - The only sad person to take on the FAQ because I was getting annoyed at the number of 'petty' tcp/ip code problems being asked on the net. Besides of which I wanted to give something useful towards Linux which I've used since 0.10 (does this make me a veteran?) Phil (The non spell checking insomniacial/palagerist who never learnt =--= english grammer)