Differences

This shows you the differences between two versions of the page.

--- usermanual [2006/07/19 14:58]
stockholm created from user manual
+++ usermanual [2006/07/21 05:17] (current)
stockholm
@@ Line 14: / Line 14: @@
 ===== About this User Manual =====
 ==== Obtaining the most recent version of this document ====
-This document and related documents are also kept online at the Etherboot Home Page. This will in general have the latest source distributions and documentation.
+This document and related documents are also kept online at the [[http://www.etherboot.org/|Etherboot Home Page]]. This will in general have the latest source distributions and documentation.
 ==== Feedback ====
-Comments on and corrections for this User Manual may be directed to the primary author.
+Comments on and corrections for this User Manual may be directed to [[mailto:ken_yapATusersPERIODsourceforgePERIODnet|the primary author]].
 ==== Copyrights and Trademarks ====
 This manual may be reproduced in whole or in part, without fee, subject to the following restrictions:
@@ Line 24: / Line 24: @@
   * Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. Exceptions to these rules may be granted for academic purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to restrict you as learners and educators.
   * All trademarks mentioned in this document belong to their respective owners.
 ==== Acknowledgments and Thanks ====
 Thanks to Markus Gutschke who wrote the first version of this document, and to all the people who have contributed information and corrections to this document.
-For a list of people who have contributed substantially to the code, please see the *FIXME* Section called Acknowledgements section.
+For a list of people who have contributed substantially to the code, please see the [[#Acknowledgements|Acknowledgements section]].
 ===== Introduction to Etherboot =====
@@ Line 38: / Line 39: @@
 ==== License ====
-Etherboot is Open Source under the GNU General Public License Version 2 (GPL2). The license conditions can be obtained from the file COPYING in the top directory of the distribution or viewed at [[http://www.gnu.org|www.gnu.org]]. In particular note that if you are distributing binaries generated from Etherboot, such as ROMs or ROM images, you must provide or promise to provide the user with the source. If you have not made private changes to the code, you can do this by pointing the user to the Etherboot home page, noting the release version of course. If you have made private changes to the code, then you must distribute those changes too with binary distributions.
+Etherboot is Open Source under the GNU General Public License Version 2 (GPL2). The license conditions can be obtained from the file COPYING in the top directory of the distribution or viewed at [[http://www.gnu.org|www.gnu.org]]. In particular note that if you are distributing binaries generated from Etherboot, such as ROMs or ROM images, you must provide or promise to provide the user with the source. If you have not made private changes to the code, you can do this by pointing the user to the [[http://www.etherboot.org/|Etherboot home page]], noting the release version of course. If you have made private changes to the code, then you must distribute those changes too with binary distributions.
 The following is not legal advice and you should seek your own legal advice but it is a reasonable interpretation of the GPL with respect to Etherboot and BIOS code. Installing Etherboot, either as an extension BIOS or combined in the BIOS chip is mere aggregation. The GPL does not extend to other works that a GPLed binary is aggregated with on a storage medium. The rationale is this: The BIOS does not need an Etherboot ROM to function and the Etherboot ROM can work equally well with another BIOS implementation. Therefore putting Etherboot either on a ROM chip or in the same chip as the BIOS does not cause the two to become a combined work. Under this interpretation, there is no fear that you have to GPL your BIOS if you ship Etherboot with your BIOS.
-The GPL applies to the whole package but a few files may be used under other licenses for historical reasons. See the Section called Source copyrights for details. Please support Open Source by joining the community and sharing. See the Etherboot home page for some ways you can help Etherboot.
+The GPL applies to the whole package but a few files may be used under other licenses for historical reasons. See the [[#source_copyrights|Source copyrights section]] for details. Please support Open Source by joining the community and sharing. See the [[http://www.etherboot.org/|Etherboot home page]] (or [[contributing|Contributing]]) for some ways you can help Etherboot.
 No Warranty or Support: Etherboot comes with NO warranties of any kind. It is hoped that it will be useful to you, but NO responsibility is accepted for any outcome of using it. Etherboot also comes with NO support, although you may get helpful advice from the mailing lists listed on the Etherboot home page.
 ==== What hardware is supported? ====
-See Appendix A for a list of supported NICs. All Etherboot drivers are autoprobing, which means they attempt to detect the hardware addresses at which the card is installed. It's fairly easy to write a driver if you know C and are familiar with Ethernet hardware interfacing. Please read the developer manual if you wish to do so.
+See [[#list_of_supported_nics|Appendix]] for a list of supported NICs. All Etherboot drivers are autoprobing, which means they attempt to detect the hardware addresses at which the card is installed. It's fairly easy to write a driver if you know C and are familiar with Ethernet hardware interfacing. Please read the [[dev:devmanual|developer manual]] if you wish to do so.
 ==== Getting help ====
-Please join the Etherboot mailing lists. These are listed on the Etherboot home page. There is a users mailing list and a developers mailing list. The users list is for issues with building and running the software, while the developers list is for issues with features and coding.
+Please join the Etherboot [[http://sourceforge.net/mail/?group_id=4233|mailing lists]] (Update AMH2006: Nowadays, only ''etherboot-discuss'' is an active discussion list). These are listed on the [[http://www.etherboot.org/|Etherboot home page]]. There is a users mailing list and a developers mailing list. The users list is for issues with building and running the software, while the developers list is for issues with features and coding.
 Please post questions or bug reports to the Etherboot mailing lists, please do not mail me, because: 1. you get the benefit of a lot of experts seeing your question (no, I don't know everything, if only because there are many configurations I have never used); 2. a lot of people see the question and answer and this helps them too; 3. I have other demands on my time, like a job, and answering individual email is an unsustainable practice. You will probably not get any reply from me if you email me directly. I want to make the best use of my time and that is by making sure that as many people as possible see the questions and answers. Note that I will post my replies to the mailing lists so to see the answers you should subscribe, or be willing to check the archives later.
@@ Line 56: / Line 57: @@
 On the other hand, if you have a code or document contribution, then email to me is definitely appropriate. Please ask first before you send large files. Diffs are preferred to entire archives. If you are really keen to volunteer, and have the skills, ask to join the developer team.
-Other lists you can join are the Linux Terminal Server Project mailing lists at LTSP. The LTSP list is focused more on the LTSP packages. However there is a fair amount of overlap between the lists and many key people are on all lists.
+Other lists you can join are the [[http://www.ltsp.org/|Linux Terminal Server Project]] mailing lists at LTSP. The LTSP list is focused more on the LTSP packages. However there is a fair amount of overlap between the lists and many key people are on all lists.
 ===== Unpacking, compiling and testing the package =====
 ==== A short cut to getting Etherboot images ====
- Marty Connor has set up a web form for creating an Etherboot image [[http://www.rom-o-matic.net/|Rom-o-Matic]] on the fly and returning it as the output of the form. If all you want is an Etherboot image, this could save you having to build the distribution.
+ Marty Connor has set up a [[http://www.rom-o-matic.net/|web form for creating an Etherboot image (Rom-o-Matic)]] on the fly and returning it as the output of the form. If all you want is an Etherboot image, this could save you having to build the distribution.
 ==== Unpacking the distribution ====
@@ Line 81: / Line 83: @@
 </file>
 which will extract the documentation in a subdirectory of the Etherboot top directory.
 ==== Making an Etherboot image ====
 To build an Etherboot image you need a recent release of gcc and the binutils tools. This package has been compiled with the tools from a SuSE 8.2 distribution but it should work with any recent Linux or FreeBSD distribution. gas 2.9.1 is too old to handle the 16-bit code in loader.S. Use gas 2.9.5 at least. Also the "gcc 2.96" used in RedHat 7.0 (and later versions maybe) generates faulty machine code compiling Etherboot. Use kgcc from those distributions instead.
@@ Line 103: / Line 106: @@
 The ones ending in ''.zlilo'' look sufficiently like Linux kernel images to be accepted by [[http://lilo.go.dyndns.org/|LILO]], [[http://www.gnu.org/software/grub/grub.html|GRUB]] and [[http://www.zytor.com/syslinux/|SYSLINUX]] for installation. Unfortunately loadlin uses a slightly different method of booting for Linux kernels from LILO and SYSLINUX and will not work with these images.
- The fact that ''.zlilo'' images look like a Linux kernel to LILO and SYSLINUX allows some interesting booting possibilities. For example, you could use LILO to select between DOS/Windows and Etherboot images from a disk that contains no Linux partitions, only FAT based partitions. *FIXME* This HOWTO shows you how this can be arranged.
+ The fact that ''.zlilo'' images look like a Linux kernel to LILO and SYSLINUX allows some interesting booting possibilities. For example, you could use LILO to select between DOS/Windows and Etherboot images from a disk that contains no Linux partitions, only FAT based partitions. [[lilowithetherboot|This HOWTO]] shows you how this can be arranged.
- The ones ending in ''.zpxe'' can be booted by a PXE booter. This is useful to chain to Etherboot from PXE. *FIXME* Here are some notes on how to combine PXE and Etherboot.
+ The ones ending in ''.zpxe'' can be booted by a PXE booter. This is useful to chain to Etherboot from PXE. [[pxe2ndstage|Here are]] some notes on how to combine PXE and Etherboot.
 The ones ending in ''.com'' are DOS format executables, suitable for starting from DOS. It requires a real DOS environment, not a virtual DOS environment such as that provided by the DOS prompt window under Windows. Also it requires that there be no XMS drivers or other memory handlers loaded. It is not guaranteed to work if the environment is not clean, and sometimes not even if it is. The best chance of this format working is when DOS is booted with no device drivers whatsoever. If you can, use raw floppy or an intermediate bootloader for booting instead.
-The ones ending in ''.zrom'' are images suitable for writing onto ROMs. If you are making a ''.zrom'' image, you must set the PCI vendor and device IDs correctly for PCI NICs. Look at the file NIC. Locate the line that has the correct PCI IDs for your NIC. This will give you the name of the ROM image you should use. The PCI IDs are usually displayed by the BIOS on booting up. They can also be read out from a running Linux system using the Linux PCI Utilities. If you do not use the ROM with the correct IDs, the floppy version will work, but the ROM will not since the BIOS will check for a match.
+The ones ending in ''.zrom'' are images suitable for writing onto ROMs. If you are making a ''.zrom'' image, you must set the PCI vendor and device IDs correctly for PCI NICs. Look at the file NIC. Locate the line that has the correct PCI IDs for your NIC. This will give you the name of the ROM image you should use. The PCI IDs are usually displayed by the BIOS on booting up. They can also be read out from a running Linux system using the [[http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml|Linux PCI Utilities]]. If you do not use the ROM with the correct IDs, the floppy version will work, but the ROM will not since the BIOS will check for a match.
 There are also ''.fd0'', ''.dsk'', ''.lilo'', ''.pxe'' and ''.rom'' counterparts to the ''.z*'' versions of the images. The difference is the ''.z*'' versions are compressed. Unless you doubt the (de)compression process, there is usually no reason to use the uncompressed versions..
@@ Line 115: / Line 118: @@
 ===== Setting up a diskless boot =====
 In this section I assume you want to boot a Linux kernel. Booting a FreeBSD kernel is documented elsewhere and does not require a generating a boot image. Booting a DOS kernel is similar, the main differences being in the way you set up the boot image.
 ==== Making a boot image ====
-Etherboot expects to download a boot image in either ELF or tagged format containing the code to be executed. Briefly explained, a boot image has a wrapper around the pieces of code or data that need to be put in various places in the computer's memory. It contains a directory telling how large the pieces are and where they go in memory. It also says where to start execution.
+Etherboot expects to download a boot image in either ELF or [[dev:devmanual#image_format_with_initial_magic_number|tagged format]] containing the code to be executed. Briefly explained, a boot image has a wrapper around the pieces of code or data that need to be put in various places in the computer's memory. It contains a directory telling how large the pieces are and where they go in memory. It also says where to start execution.
-A boot image is created using a utility program. The utility program is specific to the kernel you want to load. The version for Linux is called ''mkelf-linux'' or ''mknbi-linux'' and that for DOS is ''mknbi-dos''. These utilities are distributed separately and can be obtained from Etherboot web site.
+A boot image is created using a utility program. The [[mknbi|utility program]] is specific to the kernel you want to load. The version for Linux is called ''mkelf-linux'' or ''mknbi-linux'' and that for DOS is ''mknbi-dos''. These utilities are distributed separately and can be obtained from [[http://www.etherboot.org|Etherboot web site]].
 ==== Compiling a custom kernel ====
@@ Line 185: / Line 189: @@
  If you have a DHCP server already running for the subnet, you probably should specify that your additional ISC DHCPD server is not authoritative for the the subnet, or it will veto (NAK) existing client IP address allocations, upsetting the status quo. See the ISC DHCPD options documentation.
-Here is a practical document describing how it is done.
+Here is a practical document (AMH2006: Dead link, sorry) describing how it is done.
 ==== Setting up a tftp daemon ====
@@ Line 200: / Line 204: @@
 Recent advances in the Linux kernel (2.4 and above) have made the use of an initrd that does user space autoconfiguration and mounting of a NFS root filesystem, followed by a pivot_root, a more flexible alternative to kernel autoconfiguration and mounting of a NFS root filesystem. Postings on the kernel mailing lists indicate that at some point in the future, kernel level autoconfiguration (BOOTP/DHCP from the kernel) may be removed from the Linux kernel and initrds will be the recommended way to start up a diskless system.
-Until I have time to write detailed instructions on how to construct the initrd, I refer you to the LTSP distribution which uses this technique. Mknbi supports initrds, see the ramdisk argument of mkelf-linux. The Linux kernel documentation describes the extra arguments should be passed to the kernel to make it use an initrd, and how to arrange the initrd so that the startup script within it is called when it's mounted. If the initrd mounts a NFS root filesystem then it should still have all the needed structure as explained in the next section.
+Until I have time to write detailed instructions on how to construct the initrd, I refer you to the [[http://www.ltsp.org/|LTSP distribution]] which uses this technique. Mknbi supports initrds, see the ramdisk argument of [[mknbi|''mkelf-linux'']]. The Linux kernel documentation describes the extra arguments should be passed to the kernel to make it use an initrd, and how to arrange the initrd so that the startup script within it is called when it's mounted. If the initrd mounts a NFS root filesystem then it should still have all the needed structure as explained in the next section.
+Initrds can also be used for mounting other network filesystems instead of NFS root. Some applications could even run totally out of initrd, e.g. [[http://www.zelow.no/floppyfw/|Floppy Firewall]], provided you have the memory, of course.
-Initrds can also be used for mounting other network filesystems instead of NFS root. Some applications could even run totally out of initrd, e.g. Floppy Firewall, provided you have the memory, of course.
 ==== Other filesystem setups ====
-This tutorial does not cover all possible ways of setting up a diskless client's initial filesystem. You could even mount a conventional hard disk. Why would you want to boot "diskless" if you have a hard disk? Reasons might be: you do not wish to administer the local disk; you want the assurance that a system is running a kernel from a central server; or you like the speed of network booting. Network booting is one technique in a toolbox. Techniques can be combined to do what you want. If you are interested in running the diskless client as an X-terminal, a very common use, you may wish to investigate the Linux Terminal Server Project.
+This tutorial does not cover all possible ways of setting up a diskless client's initial filesystem. You could even mount a conventional hard disk. Why would you want to boot "diskless" if you have a hard disk? Reasons might be: you do not wish to administer the local disk; you want the assurance that a system is running a kernel from a central server; or you like the speed of network booting. Network booting is one technique in a toolbox. Techniques can be combined to do what you want. If you are interested in running the diskless client as an X-terminal, a very common use, you may wish to investigate the [[http://www.ltsp.org/|Linux Terminal Server Project]].
 ==== Swap over NFS ====
-Swap over NFS can be arranged but you have to patch the kernel source. See here.
+Swap over NFS can be arranged but you have to patch the kernel source. See [[http://nfs-swap.dot-heine.de/|here]].
 Be aware that opinions are divided on NFS swap. Some people think it's a bad thing because it just kills the network if you have lots of diskless computers and that you shouldn't be running into a swap regime on a diskless computer anyway. Some other people like having a bit of insurance.
-Also have a look at the NBD Network Block Device for swapping over that.
+Also have a look at the [[http://atrey.karlin.mff.cuni.cz/~pavel/nbd/nbd.html|NBD Network Block Device]] for swapping over that.
-There is also the follow-on project ENBD, the Enhanced Network Block Driver. I have no experience with this for swapping. Comments welcome.
+There is also the follow-on project [[http://www.it.uc3m.es/~ptb/nbd/|ENBD]], the Enhanced Network Block Driver. I have no experience with this for swapping. Comments welcome.
 ===== Booting DOS =====
-What about DOS? The deal with DOS is that one is loading a virtual floppy called A: into extended memory and then booting from this floppy. So you have to capture an image of a bootable DOS floppy first. Some more details can be found in the mknbi-dos utility.
+What about DOS? The deal with DOS is that one is loading a virtual floppy called A: into extended memory and then booting from this floppy. So you have to capture an image of a bootable DOS floppy first. Some more details can be found in the [[mknbi|''mknbi-dos'']] utility.
-I have booted DOS (both M$ versions up to 5.0 and DR versions up to 7.03) diskless this way. A mknbi-fdos is available for building boot images for booting FreeDOS, the procedure differs slightly from booting M$ or DR DOS.
+I have booted DOS (both M$ versions up to 5.0 and DR versions up to 7.03) diskless this way. A [[mknbi|''mknbi-fdos'']] is available for building boot images for booting FreeDOS, the procedure differs slightly from booting M$ or DR DOS.
-If you were thinking of booting a Windows machine via the network, it seems (I'm not masochistic enough to do this) the problem is not the network booting but the mounting of a file system over NetBIOS (Windows does not do remote mounts of root filesystems over NetBIOS on TCP). So that rules out a Samba server. It appears to be possible over a Netware server, for which Linux or FreeBSD has workalikes. Also it is said that only certain versions of Windows will allow diskless booting. You will also have problems with pathnames and the usual Windows hassles. Do you really want to do this? You do know that you can run lots of desktop applications like Netscape, StarOffice, etc. on Linux, FreeBSD, etc. now? Why pay good money when you can use equally good free replacements? Anyway if you are still determined, in the Etherboot home page, there are links to external Web pages, one explaining how this was done with a commercial TCP/IP boot ROM, another explaining how to do it using Etherboot and Netbios over IPX. A recent user experience is here. Good luck and send us your experiences or better still a URL to a page explaining how you did it.
+If you were thinking of booting a Windows machine via the network, it seems (I'm not masochistic enough to do this) the problem is not the network booting but the mounting of a file system over NetBIOS (Windows does not do remote mounts of root filesystems over NetBIOS on TCP). So that rules out a Samba server. It appears to be possible over a Netware server, for which Linux or FreeBSD has workalikes. Also it is said that only certain versions of Windows will allow diskless booting. You will also have problems with pathnames and the usual Windows hassles. Do you really want to do this? You do know that you can run lots of desktop applications like Netscape, StarOffice, etc. on Linux, FreeBSD, etc. now? Why pay good money when you can use equally good free replacements? Anyway if you are still determined, in the [[http://www.etherboot.org/|Etherboot home page]], there are links to external Web pages, one explaining how this was done with a commercial TCP/IP boot ROM, another explaining how to do it using Etherboot and Netbios over IPX. A recent user experience is (AMH2006: Dead link, sorry) here. Good luck and send us your experiences or better still a URL to a page explaining how you did it.
 ===== Making an Etherboot EPROM or EEPROM =====
-Assuming you have satisfactorily set up your server environment, you may now wish to put the Etherboot onto an EPROM or EEPROM. Naturally this assumes access to hardware to program (and possibly erase) EPROMs. Access to a friendly electronics engineer and/or lab is one way to program and erase EPROMs. Otherwise you can look at the commercial links page for places you can buy programmed EPROMs from.
+Assuming you have satisfactorily set up your server environment, you may now wish to put the Etherboot onto an EPROM or EEPROM. Naturally this assumes access to hardware to program (and possibly erase) EPROMs. Access to a friendly electronics engineer and/or lab is one way to program and erase EPROMs. Otherwise you can look at the [[commerciallinks|commercial links page]] for places you can buy programmed EPROMs from.
 Some high-end network cards, for example the 3Com 905B, have a socket for an EEPROM which can be programmed in situ with the right utilities. See any release notes accompanying Etherboot for more information.
@@ Line 230: / Line 236: @@
 ==== Enabling the EPROM ====
 First you must discover how to enable the EPROM socket on your card. Typically the EPROM is not enabled from the factory and a jumper or a software configuration program is used to enable it.
 ==== Size and speed of the EPROM ====
 Secondly, you must discover what size and speed of EPROM is needed. This can be difficult as network card manufacturers often neglect to provide this information.
@@ Line 245: / Line 252: @@
 The speed of the EPROM needed depends on how it is connected to the computer bus. If the EPROM is directly connected to the computer bus, as in the case of many cheap NE2000 clones, then you will probably have to get an EPROM that is at least as fast as the ROMs used for the main BIOS. This is typically 120-150 ns. Some network cards mediate access to the EPROM via circuitry and this may insert wait states so that slower EPROMs can be used. Incidentally the slowness of the EPROM doesn't affect Etherboot execution speed much because Etherboot copies itself to RAM before executing.
-If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities here. The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site here.
+If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities [[http://srecord.sourceforge.net/index.html|here]]. The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found [[dev:bin2intelhexc|in this wiki here]].
 Etherboot is believed to make PnP compliant ROMs for PCI NICs. A long-standing bug in the headers has been tracked down. However some faulty old BIOSes are out there so I have written a Perl script swapdevids.pl to switch the header around if necessary. You'll have to experiment with it both ways to find out which works. Or you could dump a ROM image that works (e.g. RPL, PXE ROM) using the Perl script disrom.pl. The fields to look at are Device (base, sub, interface) Type. It should be 02 00 00, but some BIOSes want 00 00 02 due to ambiguity in the original specification.
 ===== Troubleshooting tips =====
@@ Line 263: / Line 268: @@
   * Etherboot detects card but does nothing after saying Searching for server. Check your network hardware. Did you select the right hardware interface (AUI, BNC, RJ45)? Is the cabling ok? If you have a Unix computer on the network and have root privileges, you could run tcpdump or ethereal looking for broadcast packets on the bootps port. If the requests are getting sent out but no replies are getting back, check your DHCPD setup. Also check if the server has a route to the client.
   * Etherboot obtains IP address but fails to load file. Check the tftp server. Is the boot image file installed? Is the file world readable? Is the path to the file allowed by the configuration of tftpd? Is the client denied by tcpwrapper rules? Did you put the right home directory and filename in /etc/dhcpd.conf? If you are booting lots of clients, is inetd shutting down tftpd for being spawned too often? If so, you need to get a better inetd or a a dedicated tftpd that runs as an independent daemon.
-  * Etherboot loads file but hangs halfway through the transfer. We have one report that this happens if the Fast A20 Gate option is selected in the BIOS setup. The A20 issue is explained here. In effect this causes the loaded kernel to overwrite Etherboot and kill it. Try deselecting the option. You don't need it for Linux anyway.
+  * Etherboot loads file but hangs halfway through the transfer. We have one report that this happens if the Fast A20 Gate option is selected in the BIOS setup. The A20 issue is explained [[http://www.win.tue.nl/~aeb/linux/kbd/A20.html|here]]. In effect this causes the loaded kernel to overwrite Etherboot and kill it. Try deselecting the option. You don't need it for Linux anyway.
   * Etherboot loads file via tftp but Linux fails to mount the root filesystem, either on an initrd or on NFSroot. This is a large category. Here are some suggestions:
     * You do not have a private copy of the /, /etc, /var, ... directories
@@ Line 306: / Line 311: @@
   * Why don't you provide prebuilt ROM images?
     * [[http://www.rom-o-matic.net/|rom-o-matic.net]] is the answer. This is a site that makes ROM images for you on demand from specifications given to a web form and returns the image as the result of the form.
 ==== Testing Etherboot ====
   * I put the ROM image on floppy like you wrote (''cat bin/boot1a.bin bin/foo.rom > /dev/fd0, or make bin/foo.fd0'') but the loader prints out an error.
@@ Line 318: / Line 324: @@
     * Access violation is a blanket reply for many different problems but essentially the TFTP server cannot give Etherboot the file requested. Did you put the file where TFTPD expects to find it, e.g. on a directory that is on its path? Did you make the file world readable? Case of the filename is important too. Check the log files on the TFTP server to see what the actual filename it tried to open was, sometimes directory prefixes are prepended to the name due to the program options specified.
   * I made this kernel and put it in /tftpdir like you wrote but Etherboot says Unable to load file.
-    * Is the file a boot image? You cannot use a ordinary kernel image, you must process it with mkelf-linux first.
+    * Is the file a boot image? You cannot use a ordinary kernel image, you must process it with [[mknbi|mkelf-linux]] first.
   * I have this proprietary boot ROM (e.g. LanWorks, PXE, etc) and I used mkelf-linux or mknbi-linux to make a boot image, (or I got this boot image from the LTSP project), but the boot ROM doesn't load it, or it fails to run.
-    * The boot image format is specific to Etherboot. It will not work with proprietary boot ROMs. You have to find out from the supplier what boot procedures you should use. For example, if you are using a LanWorks boot ROM, the information you need is here. For PXE the utility you need is PXELINUX.
+    * The boot image format is specific to Etherboot. It will not work with proprietary boot ROMs. You have to find out from the supplier what boot procedures you should use. For example, if you are using a LanWorks boot ROM, the information you need is [[http://www.3com.com/managedpc|here]]. For PXE the utility you need is PXELINUX.
 ==== Hardware capabilities ====
   * What network cards are supported?
@@ Line 326: / Line 333: @@
   *  I have a machine with the X processor and Y megabytes of memory. What can I expect to run on it?
     * Please note that these estimates are approximate:
-    * On a 386 with at least 4MB of memory you can boot Linux. With 4MB perhaps only a few telnet sessions are possible. With 8MB you might be able to run a text based web browser like Lynx or W3M. You can also run firewalls such as floppyfw.
+    * On a 386 with at least 4MB of memory you can boot Linux. With 4MB perhaps only a few telnet sessions are possible. With 8MB you might be able to run a text based web browser like Lynx or W3M. You can also run firewalls such as [[http://www.zelow.no/floppyfw/|floppyfw]].
     * On a 486 with 16MB of memory you can run X to make an X-terminal.
     * On a Pentium with 32MB of memory you can run an X-terminal and some applications locally, say perhaps printing, daemons to control devices, etc.
     * On anything faster and with more memory you could perhaps do distributed computation, e.g. a cluster.
 ==== Booting Linux ====
   * The kernel loads but it cannot find a NFS server for the filesystem.
     * Do you have a NFS server running and is it allowed to serve this client? NFS is actually several services. On Linux at least you need: nfsd (either kernel or userland version), rpc.mountd and portmapper. Check if the tcpwrappers config file is allowing portmapper to receive the request. Look at the log files for clues. Did we already mention that log files are your friends?
   * The filesystem mounts but it says something about not being able to open an initial console. Or alternatively, various services complain about not being able to write to the filesystem.
-    * A common mistake in Linux NFS servers is to put extra spaces in /etc/exports. Please see the NFS FAQ for frequently answered questions about Linux NFS services.
+    * A common mistake in Linux NFS servers is to put extra spaces in /etc/exports. Please see the [[http://nfs.sourceforge.net/|NFS FAQ]] for frequently answered questions about Linux NFS services.
-    * Please review the Troubleshooting section for what is required on this root filesystem. The situation is complicated by the fact that there are many possible ways of setting this up, including using a root filesystem that is on ramdisk. If you wish to avoid many of the troubles, try using a packaged solution such as LTSP.
+    * Please review the Troubleshooting section for what is required on this root filesystem. The situation is complicated by the fact that there are many possible ways of setting this up, including using a root filesystem that is on ramdisk. If you wish to avoid many of the troubles, try using a packaged solution such as [[http://www.ltsp.org/|LTSP]].
 ==== Running X ====
   * I tried to run X on the client but it aborted.
@@ Line 353: / Line 362: @@
     * If you want to run apps locally, well how long is a piece of string? Netscape will need say another 16MB. It all depends. Whatever you do, it's worth trimming down on the services you run on the client. Don't run more virtual consoles than you need and don't run unneeded daemons.
     * As for the server, in the X-terminal case this has all the applications running on it, so it should be adequate for the multiuser aspect. A high-end Pentium, with 64 MB of memory to start with, and between 8 and 16MB for each extra client is a good starting point. It will also depend on your mix of client access, statistically perhaps not everybody will be running at the same time. Remember that you don't have to have one big server for all your clients, you can and you should distribute the load across servers.
 ==== Other client applications ====
   * How can I print to a printer attached to a diskless client?
-    * There is a server program called p910nd at the Etherboot web site that funnels data from a TCP/IP connection to the printer port. You can instruct lpd or CUPS on the server to send jobs across the network to p910nd.
+    * There is a server program called [[http://www.etherboot.org/p910nd/|p910nd]] at the Etherboot web site that funnels data from a TCP/IP connection to the printer port. You can instruct lpd or [[http://www.cups.org/|CUPS]] on the server to send jobs across the network to p910nd.
   * How can I output sound on the client?
-    * There is a package called virtualfs that proxies the sound devices across the network. It can also proxy the floppy drive.
+    * There is a package called [[http://www.solucorp.qc.ca/|virtualfs]] that proxies the sound devices across the network. It can also proxy the floppy drive.
-    * Another solution is EsounD
+    * Another solution is [[http://www.tux.org/~ricdude/EsounD.html|EsounD]]
-    * You may wish to check the LTSP site and mailing lists for other proposed solutions.
+    * You may wish to check the [[http://www.ltsp.org/|LTSP site]] and mailing lists for other proposed solutions.
   * How can I access the floppy on the client?
-    * Besides virtualfs mentioned above, recent distributions of mtools have a floppyd. This only works with the mtools utilities though.
+    * Besides virtualfs mentioned above, recent distributions of [[http://wauug.erols.com/pub/knaff/mtools/|mtools]] have a floppyd. This only works with the mtools utilities though.
 ==== Booting FreeBSD ====
   * Where are the instructions for booting FreeBSD?
     * For now, there is just a short document in the doc directory. Better versions of this document depend on contributions from the FreeBSD community, I am unable to test FreeBSD because I don't run it.
 ==== Booting other operating systems (DOS, Windows) ====
   * I want to boot FreeDOS.
-    * The new mknbi utility supports creating boot images from FreeDOS kernels now. See the man page for details. FreeDOS is under development and if the layout of the kernel image changes, please send any corrections to me.
+    * The new ''mknbi'' utility supports creating boot images from FreeDOS kernels now. See the [[mknbi|man page]] for details. FreeDOS is under development and if the layout of the kernel image changes, please send any corrections to me.
   * I cannot boot DR-DOS 7.03.
     * There is some difference between the DR-DOS 7.03 and 7.02 bootblock that causes it not to boot. But a 7.02 bootblock works just as well with the DR-DOS 7.03 kernel, so you can substitute that.
@@ Line 373: / Line 385: @@
     * Use the /testmem:off option to prevent HIMEM from scribbling over the ramdisk which is the floppy A:.
   * How do I make A: my real floppy again after booting is complete?
-    * Use the rmrd.com program supplied with mknbi.
+    * Use the ''rmrd.com'' program supplied with [[mknbi|''mknbi'']].
   * I want to use the real floppy at the same time I am using the ramdisk image of the boot floppy.
-    * The ''--harddisk'' option of ''mknbi-dos'' is intended for this. It causes your boot drive to be C:, so you can use A: for the real floppy. See the man page for more details
+    * The ''--harddisk'' option of ''mknbi-dos'' is intended for this. It causes your boot drive to be C:, so you can use A: for the real floppy. See the [[mknbi|man page]] for more details
   * I want to boot Windows.
     * I pass on this one, as I do not have (by choice) any Windows systems running on my computers. Perhaps others can contribute to this section. However I gather that it is only possible on Windows95A, as other versions don't have the necessary support for diskless booting.
 ==== Hardware issues ====
   * Where can I get an EPROM made?
     * Depending on where you live, you might find a supplier listed on the Commercial Links page. Another possibility is to seek the help of someone working in a university or industrial lab who has an EPROM programmer. If you are handy with hardware, you could buy a kit or build your own. There are links to kit suppliers in the Commercial Links part of the home page.
     * Some high end adapters, for example the 3Com and Intel ones, accept an EEPROM in the socket. This can be programmed in-situ using utility programs, some of which or information about are under the contrib directory in the Etherboot distribution.
-    * Finally some recent motherboard have flash BIOSes which contain space where an extension BIOS such as Etherboot can be inserted. The Phoenix Award BIOSes can be modified using a program called cbrom.exe possibly here. Or do a Web search for it. No success has been reported for AMI BIOSes. Dirk von Suchodoletz maintains a list of successes and failures here.
+    * Finally some recent motherboard have flash BIOSes which contain space where an extension BIOS such as Etherboot can be inserted. The Phoenix Award BIOSes can be modified using a program called [[http://www.ping.be/bios|''cbrom.exe'']] possibly here. Or do a Web search for it. No success has been reported for AMI BIOSes. Dirk von Suchodoletz maintains a list of successes and failures [[http://goe.net/anleitungen/award_board.html|here]].
+(AMH2006:) Information about [[biosmodule|flashing EtherBoot into your BIOS]] is also available on a separate wiki page.
 Here is some text contributed by Dirk von Suchodoletz. He hopes to put it on a web site someday:
 <file>
@@ Line 477: / Line 493: @@
 </file>
   * How do I enable the ROM socket on my network adapter? There are no jumpers on the card.
-    * These jumperless cards need a card-specific utility program to enable the ROM. Normally the manufacturer supplies it on a diskette or CDROM. You lost the diskette? If you know the manufacturer, you might be able to get the program from their website. You have a mystery card? Well the first thing to do is to identify the card. If it is an ISA card and made in Taiwan or China it's almost certainly a NE2000 clone. For some information, try here. If it's a PCI card, then either the BIOS or the Linux PCI Utilities should be able to tell you the manufacturer and device IDs, which you can then look up to convert to names.
+    * These jumperless cards need a card-specific utility program to enable the ROM. Normally the manufacturer supplies it on a diskette or CDROM. You lost the diskette? If you know the manufacturer, you might be able to get the program from their website. You have a mystery card? Well the first thing to do is to identify the card. If it is an ISA card and made in Taiwan or China it's almost certainly a NE2000 clone. For some information, try [[http://www.geocities.com/ken_yap_aus/|here]]. If it's a PCI card, then either the BIOS or the [[http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml|Linux PCI Utilities]] should be able to tell you the manufacturer and device IDs, which you can then look up to convert to names.
   * I would like to boot my laptop diskless from a floppy containing Etherboot.
     * The problem is that laptops these days use PCMCIA network adapter cards. These in turn connect to the PCMCIA controller when docked. To be able to communicate with the PCMCIA card, Etherboot would first have to talk to the PCMCIA controller. Until somebody writes the code to do this... Booting from disk is different because the kernel will load the PCMCIA controller code from disk first. You could always put a Linux kernel on the boot floppy.
 ==== Drivers ====
   * There is no Etherboot driver for my network adapter. Can you write me one?
-    * If I were independently wealthy and had nothing else to do in life, sure! But unfortunately I have a day job and Etherboot is a hobby. A couple of the drivers were written for pay and the others were written by volunteers. Perhaps you might like to volunteer? If you have a good grasp of C, and understand basic hardware concepts, it is quite doable, and not nearly as difficult as writing a Linux device driver. See the developer manual. You will have the reward of understanding hardware intimately and seeing your work benefit users worldwide.
+    * If I were independently wealthy and had nothing else to do in life, sure! But unfortunately I have a day job and Etherboot is a hobby. A couple of the drivers were written for pay and the others were written by volunteers. Perhaps you might like to volunteer? If you have a good grasp of C, and understand basic hardware concepts, it is quite doable, and not nearly as difficult as writing a Linux device driver. See the [[dev:devmanual|developer manual]]. You will have the reward of understanding hardware intimately and seeing your work benefit users worldwide.
-    * If you are a commercial entity, you might consider assigning staff or hiring a volunteer to write the driver. You get the benefit of the rest of the Etherboot code infrastructure and users worldwide get to appreciate your contribution. Bear in mind license conditions detailed in the Section called License, of course. NIC manufacturers note, this may be one way to attract users to your hardware products. NIC users note, petition your NIC manufacturer to support Etherboot.
+    * If you are a commercial entity, you might consider assigning staff or hiring a volunteer to write the driver. You get the benefit of the rest of the Etherboot code infrastructure and users worldwide get to appreciate your contribution. Bear in mind license conditions detailed in the [[#license|License section]], of course. NIC manufacturers note, this may be one way to attract users to your hardware products. NIC users note, petition your NIC manufacturer to support Etherboot.
   * I see that my network adapter is supported in Linux but not in Etherboot. Can I use the Linux driver in Etherboot? Or maybe you can adapt the Linux source for me. I can send you the Linux driver source if you just say the word.
     * No, the structure of Linux and Etherboot drivers are rather different. There are several reasons: Linux drivers are more complicated and written to give good performance, whereas Etherboot drivers are written to be simple. Linux drivers are interrupt driven, whereas Etherboot drivers are polling. Linux drivers have an elaborate support structure, whereas Etherboot drivers are fairly self-standing.
     * But... you can use Linux drivers as a source of reverse-engineering information. Several of the drivers in Etherboot were adapted from Linux drivers. But don't send me the driver source; see previous FAQ about volunteering. And I have the latest Linux source anyway, doesn't everyone?
 ==== Miscellaneous ====
   * I don't understand something, or I have a question not covered by this list.
-    * Please see the Section called Getting help earlier in this document.
+    * Please see the Section called [[#getting_help|Getting help]] earlier in this document.
@@ Line 564: / Line 582: @@
   * Cai Qiang - fixed the WinCE loader.
+===== Source copyrights =====
+The boot code from FreeBSD is under the BSD license. The code taken from the Linux PCI subsystem and Linux NIC drivers are under GPL. Some source files have been put under GPL by their authors. Hence the Etherboot distribution is in general under the GPL, but you may use parts of it derived from FreeBSD under FreeBSD rules. Simply speaking, the GPL says that if you distribute a binary derived from Etherboot code (this includes boot ROMs) you have to provide, or promise to provide on demand, the source code. The full conditions of the GPL are specified in the file COPYING.
+Here are the copyright details of the source, file by file:
+Unless specifically noted, a file is under the GPL.  GPLed files are in
+general either from Linux or have been explicitly put under GPL by the
+authors.  A few files are inherited from FreeBSD netboot and therefore
+can be used under BSD or GPL.
+<file>
+File                            Copyright status
+core/misc.c                     BSD
+drivers/net/3c509.c             BSD
+drivers/net/3c509.h             BSD
+drivers/net/3c595.c             BSD
+drivers/net/3c595.h             BSD
+drivers/net/3c90x.c             Open Source
+drivers/net/epic100.c           None
+drivers/net/epic100.h           None
+drivers/net/ns8390.c            BSD
+drivers/net/ns8390.h            BSD
+drivers/net/tulip.c             BSD
+arch/i386/include/bits/string.h None
+util/lzhuf.c                    Open Source
+</file>
+===== List of supported NICs =====
+The following is the current NIC configuration file as of 2003-09-23. .
+<file>
+# This is an automatically generated file, do not edit
+# It does not affect anything in the build, it's only for rom-o-matic
+family  drivers/net/skel
+skel-pci        0x0000,0x0000   Skeleton PCI Adaptor
+skel-isa        -       Skeleton ISA driver
+family  drivers/net/3c595
+c590   0x10b7,0x5900   3Com590
+c595   0x10b7,0x5950   3Com595
+c595-1 0x10b7,0x5951   3Com595
+c595-2 0x10b7,0x5952   3Com595
+c900-tpo       0x10b7,0x9000   3Com900-TPO
+c900-t4        0x10b7,0x9001   3Com900-Combo
+c900b-tpo      0x10b7,0x9004   3Com900B-TPO
+c900b-combo    0x10b7,0x9005   3Com900B-Combo
+c900b-tpb2     0x10b7,0x9006   3Com900B-2/T
+c900b-fl       0x10b7,0x900a   3Com900B-FL
+c980-cyclone-1 0x10b7,0x9800   3Com980-Cyclone
+c9805-1        0x10b7,0x9805   3Com9805
+csoho100-tx-1  0x10b7,0x7646   3CSOHO100-TX
+c450-1 0x10b7,0x4500   3Com450 HomePNA Tornado
+family  drivers/net/3c90x
+c905-tpo       0x10b7,0x9000   3Com900-TPO
+c905-t4        0x10b7,0x9001   3Com900-Combo
+c905-tpo100    0x10b7,0x9050   3Com905-TX
+c905-combo     0x10b7,0x9051   3Com905-T4
+c905b-tpo      0x10b7,0x9004   3Com900B-TPO
+c905b-combo    0x10b7,0x9005   3Com900B-Combo
+c905b-tpb2     0x10b7,0x9006   3Com900B-2/T
+c905b-fl       0x10b7,0x900a   3Com900B-FL
+c905b-tpo100   0x10b7,0x9055   3Com905B-TX
+c905b-t4       0x10b7,0x9056   3Com905B-T4
+c905b-9058     0x10b7,0x9058   3Com905B-9058
+c905b-fx       0x10b7,0x905a   3Com905B-FL
+c905c-tpo      0x10b7,0x9200   3Com905C-TXM
+c980   0x10b7,0x9800   3Com980-Cyclone
+c9805  0x10b7,0x9805   3Com9805
+csoho100-tx    0x10b7,0x7646   3CSOHO100-TX
+c450   0x10b7,0x4500   3Com450 HomePNA Tornado
+family  drivers/net/eepro100
+id1029  0x8086,0x1029   Intel EtherExpressPro100 ID1029
+id1030  0x8086,0x1030   Intel EtherExpressPro100 ID1030
+cam        0x8086,0x1031   Intel 82801CAM (ICH3) Chipset Ethernet Controller
+eepro100-1032   0x8086,0x1032   Intel PRO/100 VE Network Connection
+eepro100-1033   0x8086,0x1033   Intel PRO/100 VM Network Connection
+eepro100-1034   0x8086,0x1034   Intel PRO/100 VM Network Connection
+eepro100-1035   0x8086,0x1035   Intel 82801CAM (ICH3) Chipset Ethernet Controller
+eepro100-1036   0x8086,0x1036   Intel 82801CAM (ICH3) Chipset Ethernet Controller
+eepro100-1037   0x8086,0x1037   Intel 82801CAM (ICH3) Chipset Ethernet Controller
+id1038  0x8086,0x1038   Intel PRO/100 VM Network Connection
+et 0x8086,0x1039   Intel PRO100 VE 82562ET
+id103a  0x8086,0x103a   Intel Corporation 82559 InBusiness 10/100
+etb        0x8086,0x103b   Intel PRO100 VE 82562ETB
+eepro100-103c   0x8086,0x103c   Intel PRO/100 VM Network Connection
+eepro100-103d   0x8086,0x103d   Intel PRO/100 VE Network Connection
+eepro100-103e   0x8086,0x103e   Intel PRO/100 VM Network Connection
+qm 0x8086,0x1059   Intel PRO/100 M Mobile Connection
+er 0x8086,0x1209   Intel EtherExpressPro100 82559ER
+   0x8086,0x1227   Intel 82865 EtherExpress PRO/100A
+   0x8086,0x1228   Intel 82556 EtherExpress PRO/100 Smart
+eepro100        0x8086,0x1229   Intel EtherExpressPro100
+em 0x8086,0x2449   Intel EtherExpressPro100 82562EM
+-1 0x8086,0x2459   Intel 82562 based Fast Ethernet Connection
+-2 0x8086,0x245d   Intel 82562 based Fast Ethernet Connection
+ez 0x8086,0x1050   Intel 82562EZ Network Connection
+eepro100-5200   0x8086,0x5200   Intel EtherExpress PRO/100 Intelligent Server
+eepro100-5201   0x8086,0x5201   Intel EtherExpress PRO/100 Intelligent Server
+family  drivers/net/e1000
+e1000-82542     0x8086,0x1000   Intel EtherExpressPro1000
+e1000-82543gc-fiber     0x8086,0x1001   Intel EtherExpressPro1000 82543GC Fiber
+e1000-82543gc-copper    0x8086,0x1004   Intel EtherExpressPro1000 82543GC Copper
+e1000-82544ei-copper    0x8086,0x1008   Intel EtherExpressPro1000 82544EI Copper
+e1000-82544ei-fiber     0x8086,0x1009   Intel EtherExpressPro1000 82544EI Fiber
+e1000-82544gc-copper    0x8086,0x100c   Intel EtherExpressPro1000 82544GC Copper
+e1000-82544gc-lom       0x8086,0x100d   Intel EtherExpressPro1000 82544GC LOM
+e1000-82540em   0x8086,0x100e   Intel EtherExpressPro1000 82540EM
+e1000-82545em-copper    0x8086,0x100f   Intel EtherExpressPro1000 82545EM Copper
+e1000-82546eb-copper    0x8086,0x1010   Intel EtherExpressPro1000 82546EB Copper
+e1000-82545em-fiber     0x8086,0x1011   Intel EtherExpressPro1000 82545EM Fiber
+e1000-82546eb-fiber     0x8086,0x1012   Intel EtherExpressPro1000 82546EB Copper
+e1000-82541ei   0x8086,0x1013   Intel EtherExpressPro1000 82541EI
+e1000-82540em-lom       0x8086,0x1015   Intel EtherExpressPro1000 82540EM LOM
+e1000-82540ep-lom       0x8086,0x1016   Intel EtherExpressPro1000 82540EP LOM
+e1000-82540ep   0x8086,0x1017   Intel EtherExpressPro1000 82540EP
+e1000-82541ep   0x8086,0x1018   Intel EtherExpressPro1000 82541EP
+e1000-82547ei   0x8086,0x1019   Intel EtherExpressPro1000 82547EI
+e1000-82546eb-quad-copper       0x8086,0x101d   Intel EtherExpressPro1000 82546EB Quad Copper
+e1000-82540ep-lp        0x8086,0x101e   Intel EtherExpressPro1000 82540EP LP
+family  drivers/net/tg3
+tg3-5700        0x14e4,0x1644   Broadcom Tigon 3 5700
+tg3-5701        0x14e4,0x1645   Broadcom Tigon 3 5701
+tg3-5702        0x14e4,0x1646   Broadcom Tigon 3 5702
+tg3-5703        0x14e4,0x1647   Broadcom Tigon 3 5703
+tg3-5704        0x14e4,0x1648   Broadcom Tigon 3 5704
+tg3-5702FE      0x14e4,0x164d   Broadcom Tigon 3 5702FE
+tg3-5705        0x14e4,0x1653   Broadcom Tigon 3 5705
+tg3-5705_2      0x14e4,0x1654   Broadcom Tigon 3 5705_2
+tg3-5705M       0x14e4,0x165d   Broadcom Tigon 3 5705M
+tg3-5705M_2     0x14e4,0x165e   Broadcom Tigon 3 5705M_2
+tg3-5782        0x14e4,0x1696   Broadcom Tigon 3 5782
+tg3-5788        0x14e4,0x169c   Broadcom Tigon 3 5788
+tg3-5702X       0x14e4,0x16a6   Broadcom Tigon 3 5702X
+tg3-5703X       0x14e4,0x16a7   Broadcom Tigon 3 5703X
+tg3-5704S       0x14e4,0x16a8   Broadcom Tigon 3 5704S
+tg3-5702A3      0x14e4,0x16c6   Broadcom Tigon 3 5702A3
+tg3-5703A3      0x14e4,0x16c7   Broadcom Tigon 3 5703A3
+tg3-5901        0x14e4,0x170d   Broadcom Tigon 3 5901
+tg3-5901_2      0x14e4,0x170e   Broadcom Tigon 3 5901_2
+tg3-9DXX        0x1148,0x4400   Sysconnet 9DXX
+tg3-9MXX        0x1148,0x4500   Sysconnet 9MXX
+tg3-ac1000      0x173b,0x03e8   Altima AC1000
+tg3-ac1001      0x173b,0x03e9   Altima AC1001
+tg3-ac9100      0x173b,0x03ea   Altima AC9100
+tg3-ac1003      0x173b,0x03eb   Altima AC1003
+family  drivers/net/pcnet32
+lancepci        0x1022,0x2000   AMD Lance/PCI
+pcnetfastiii    0x1022,0x2625   AMD Lance/PCI PCNet/32
+amdhomepna      0x1022,0x2001   AMD Lance/HomePNA
+family  drivers/net/tulip
+dc21040 0x1011,0x0002   Digital Tulip
+ds21140 0x1011,0x0009   Digital Tulip Fast
+dc21041 0x1011,0x0014   Digital Tulip+
+ds21142 0x1011,0x0019   Digital Tulip 21142
+mx98713 0x10d9,0x0512   Macronix MX987x3
+mx98715 0x10d9,0x0531   Macronix MX987x5
+mxic-98715      0x1113,0x1217   Macronix MX987x5
+lc82c115        0x11ad,0xc115   LinkSys LNE100TX
+c168  0x11ad,0x0002   Netgear FA310TX
+dm9100  0x1282,0x9100   Davicom 9100
+dm9102  0x1282,0x9102   Davicom 9102
+dm9009  0x1282,0x9009   Davicom 9009
+centaur-p       0x1317,0x0985   ADMtek Centaur-P
+an981   0x1317,0x0981   ADMtek AN981 Comet
+an983   0x1113,0x1216   ADMTek AN983 Comet
+an983b  0x1317,0x9511   ADMTek Comet 983b
+centaur-c       0x1317,0x1985   ADMTek Centaur-C
+intel21145      0x8086,0x0039   Intel Tulip
+ax88140 0x125b,0x1400   ASIX AX88140
+rl100tx 0x11f6,0x9881   Compex RL100-TX
+xircomtulip     0x115d,0x0003   Xircom Tulip
+tulip-0981      0x104a,0x0981   Tulip 0x104a 0x0981
+tulip-2774      0x104a,0x2774   Tulip 0x104a 0x2774
+tulip-9511      0x1113,0x9511   Tulip 0x1113 0x9511
+tulip-1561      0x1186,0x1561   Tulip 0x1186 0x1561
+tulip-a120      0x1259,0xa120   Tulip 0x1259 0xa120
+tulip-ab02      0x13d1,0xab02   Tulip 0x13d1 0xab02
+tulip-ab03      0x13d1,0xab03   Tulip 0x13d1 0xab03
+tulip-ab08      0x13d1,0xab08   Tulip 0x13d1 0xab08
+lanfinity       0x14f1,0x1803   Conexant LANfinity
+tulip-8410      0x1626,0x8410   Tulip 0x1626 0x8410
+tulip-ab09      0x1737,0xab09   Tulip 0x1737 0xab09
+family  drivers/net/davicom
+davicom9100     0x1282,0x9100   Davicom 9100
+davicom9102     0x1282,0x9102   Davicom 9102
+davicom9009     0x1282,0x9009   Davicom 9009
+davicom9132     0x1282,0x9132   Davicom 9132
+family  drivers/net/rtl8139
+rtl8129 0x10ec,0x8129   Realtek 8129
+rtl8139 0x10ec,0x8139   Realtek 8139
+rtl8139b        0x10ec,0x8138   Realtek 8139B
+dfe538  0x1186,0x1300   DFE530TX+/DFE538TX
+smc1211-1       0x1113,0x1211   SMC EZ10/100
+smc1211 0x1112,0x1211   SMC EZ10/100
+delta8139       0x1500,0x1360   Delta Electronics 8139
+addtron8139     0x4033,0x1360   Addtron Technology 8139
+dfe690txd       0x1186,0x1340   D-Link DFE690TXD
+fe2000vx        0x13d1,0xab06   AboCom FE2000VX
+allied8139      0x1259,0xa117   Allied Telesyn 8139
+fnw3603tx       0x14ea,0xab06   Planex FNW-3603-TX
+fnw3800tx       0x14ea,0xab07   Planex FNW-3800-TX
+clone-rtl8139   0xffff,0x8139   Cloned 8139
+family  drivers/net/via-rhine
+dlink-530tx     0x1106,0x3065   VIA 6102
+via-rhine-6105  0x1106,0x3106   VIA 6105
+dlink-530tx-old 0x1106,0x3043   VIA 3043
+via6105m        0x1106,0x3053   VIA 6105M
+via-rhine-old   0x1106,0x6100   VIA 86C100A
+family  drivers/net/w89c840
+winbond840      0x1050,0x0840   Winbond W89C840F
+compexrl100atx  0x11f6,0x2011   Compex RL100ATX
+family  drivers/net/sis900
+sis900  0x1039,0x0900   SIS900
+sis7016 0x1039,0x7016   SIS7016
+family  drivers/net/natsemi
+dp83815 0x100b,0x0020   DP83815
+family  drivers/net/fa311
+fa311too        0x100b,0x0020   DP83815
+family  drivers/net/prism2_plx
+ma301   0x1385,0x4100   Netgear MA301
+c-airconnect   0x10b7,0x7770   3Com AirConnect
+ss1023  0x111a,0x1023   Siemens SpeedStream SS1023
+correga 0x15e8,0x0130   Correga
+smc2602w        0x1638,0x1100   SMC EZConnect SMC2602W
+gl24110p        0x16ab,0x1100   Global Sun Tech GL24110P
+ab-1101       0x16ab,0x1101   Unknown
+wdt11   0x16ab,0x1102   Linksys WDT11
+usr2415 0x16ec,0x3685   USR 2415
+f5d6000 0xec80,0xec00   Belkin F5D6000
+emobility       0x126c,0x8030   Nortel emobility
+family  drivers/net/prism2_pci
+prism2_pci      0x1260,0x3873   Harris Semiconductor Prism2.5 clone
+hwp01170        0x1260,0x3873   ActionTec HWP01170
+dwl520  0x1260,0x3873   DLink DWL-520
+family  drivers/net/ns8390
+rtl8029 0x10ec,0x8029   Realtek 8029
+dlink-528       0x1186,0x0300   D-Link DE-528
+winbond940      0x1050,0x0940   Winbond NE2000-PCI
+winbond940f     0x1050,0x5a5a   Winbond W89c940F
+compexrl2000    0x11f6,0x1401   Compex ReadyLink 2000
+ktiet32p2       0x8e2e,0x3000   KTI ET32P2
+nv5000sc        0x4a14,0x5000   NetVin NV5000SC
+holtek80232     0x12c3,0x0058   Holtek HT80232
+holtek80229     0x12c3,0x5598   Holtek HT80229
+surecom-ne34    0x10bd,0x0e34   Surecom NE34
+via86c926       0x1106,0x0926   Via 86c926
+wd      -       WD8003/8013, SMC8216/8416, SMC 83c790 (EtherEZ)
+ne      -       NE1000/2000 and clones
+c503   -       3Com503, Etherlink II[/16]
+family  drivers/net/epic100
+epic100 0x10b8,0x0005   SMC EtherPowerII
+smc-83c175      0x10b8,0x0006   SMC EPIC/C 83c175
+family  drivers/net/3c509
+c509   -       3c509, ISA/EISA
+c529   -       3c529 == MCA 3c509
+family  drivers/net/3c515
+c515   -       3c515, Fast EtherLink ISA
+family  drivers/net/eepro
+eepro   -       Intel Etherexpress Pro/10
+family  drivers/net/cs89x0
+cs89x0  -       Crystal Semiconductor CS89x0
+family  drivers/net/depca
+depca   -       Digital DE100 and DE200
+family  drivers/net/sk_g16
+sk_g16  -       Schneider and Koch G16
+family  drivers/net/smc9000
+smc9000 -       SMC9000
+family  drivers/net/sundance
+sundance        0x13f0,0x0201   ST201 Sundance 'Alta' based Adaptor
+dfe530txs       0x1186,0x1002   D-Link DFE530TXS (Sundance ST201 Alta)
+family  drivers/net/tlan
+netel10 0x0e11,0xae34   Compaq Netelligent 10 T PCI UTP
+netel100        0x0e11,0xae32   Compaq Netelligent 10/100 TX PCI UTP
+netflex3i       0x0e11,0xae35   Compaq Integrated NetFlex-3/P
+thunder 0x0e11,0xf130   Compaq NetFlex-3/P
+netflex3b       0x0e11,0xf150   Compaq NetFlex-3/P
+netel100pi      0x0e11,0xae43   Compaq Netelligent Integrated 10/100 TX UTP
+netel100d       0x0e11,0xae40   Compaq Netelligent Dual 10/100 TX PCI UTP
+netel100i       0x0e11,0xb011   Compaq Netelligent 10/100 TX Embedded UTP
+oc2183  0x108d,0x0013   Olicom OC-2183/2185
+oc2325  0x108d,0x0012   Olicom OC-2325
+oc2326  0x108d,0x0014   Olicom OC-2326
+netelligent_10_100_ws_5100      0x0e11,0xb030   Compaq Netelligent 10/100 TX UTP
+netelligent_10_t2       0x0e11,0xb012   Compaq Netelligent 10 T/2 PCI UTP/Coax
+family  drivers/disk/ide_disk
+ide_disk        0x0000,0x0000   Generic IDE disk support
+family  drivers/disk/pc_floppy
+pc_floppy       -       Generic PC Floppy support
+</file>
+Even if your NIC does not appear in the list, it may still be supported if the chip is one of those supported. Many OEMs use chips from foundries. An exhaustive list of brand names is impossible. The best strategy is to read the number on the LAN controller chip on the board. The following drivers have notes in the src/drivers/net directory, please read them:
+<file>
+c515.txt
+c90x.txt
+cs89x0.txt
+sis900.txt
+tulip.txt
+</file>
+===== Build options available =====
+<file>
+        User interaction options:
+        -DASK_BOOT=n
+                        Ask "Boot from (N)etwork ... or (Q)uit? "
+                        at startup, timeout after n seconds (0 = no timeout).
+                        If unset, boot immediately using the default.
+        -DBOOT_FIRST
+        -DBOOT_SECOND
+        -DBOOT_THIRD
+                        On timeout or Return key from previous
+                        question, selects the order to try to boot from
+                        various devices.
+                        (alternatives: BOOT_NIC, BOOT_DISK,
+                         BOOT_FLOPPY, BOOT_NOTHING)
+                        See etherboot.h for prompt and answer strings.
+        -DBOOT_INDEX    The device to boot from 0 == any device.
+== The first nic found.
+== The second nic found
+                        ...
+                        BOOT_INDEX only applies to the BOOT_FIRST.  BOOT_SECOND
+                        and BOOT_THIRD search through all of the boot devices.
+        -DBAR_PROGRESS
+                        Use rotating bar instead of sequential dots
+                        to indicate an IP packet transmitted.
+        Boot order options:
+        -DBOOT_CLASS_FIRST
+        -DBOOT_CLASS_SECOND
+        -DBOOT_CLASS_THIRD
+                        Select the priority of the boot classes
+                        Valid values are:
+                                BOOT_NIC
+                                BOOT_DISK
+                                BOOT_FLOPPY
+        Boot autoconfiguration protocol options:
+        -DNO_DHCP_SUPPORT
+                        Use BOOTP instead of DHCP.
+        -DRARP_NOT_BOOTP
+                        Use RARP instead of BOOTP/DHCP.
+        -DREQUIRE_VCI_ETHERBOOT
+                        Require an encapsulated Vendor Class Identifier
+                        of "Etherboot" in the DHCP reply
+                        Requires DHCP support.
+        -DALLOW_ONLY_ENCAPSULATED
+                        Ignore Etherboot-specific options that are not within
+                        the Etherboot encapsulated options field.  This option
+                        should be enabled unless you have a legacy DHCP server
+                        configuration from the bad old days before the use of
+                        encapsulated Etherboot options.
+        -DDEFAULT_BOOTFILE="default_bootfile_name"
+                        Define a default bootfile for the case where your DHCP
+                        server does not provide the information.  Example:
+                          -DDEFAULT_BOOTFILE="tftp:///tftpboot/kernel"
+                        If you do not specify this option, then DHCP offers that
+                        do not specify bootfiles will be ignored.
+        NIC tuning parameters:
+        -DALLMULTI
+                        Turns on multicast reception in the NICs.
+        Boot tuning parameters:
+        -DCONGESTED
+                        Turns on packet retransmission.  Use it on a
+                        congested network, where the normal operation
+                        can't boot the image.
+        -DBACKOFF_LIMIT
+                        Sets the maximum RFC951 backoff exponent to n.
+                        Do not set this unreasonably low, because on networks
+                        with many machines they can saturate the link
+                        (the delay corresponding to the exponent is a random
+                        time in the range 0..3.5*2^n seconds).  Use 5 for a
+                        VERY small network (max. 2 minutes delay), 7 for a
+                        medium sized network (max. 7.5 minutes delay) or 10
+                        for a really huge network with many clients, frequent
+                        congestions (max. 1  hour delay).  On average the
+                        delay time will be half the maximum value.  If in
+                        doubt about the consequences, use a larger value.
+                        Also keep in mind that the number of retransmissions
+                        is not changed by this setting, so the default of 20
+                        may no longer be appropriate.  You might need to set
+                        MAX_ARP_RETRIES, MAX_BOOTP_RETRIES, MAX_TFTP_RETRIES
+                        and MAX_RPC_RETRIES to a larger value.
+        -DTIMEOUT=n
+                        Use with care!! See above.
+                        Sets the base of RFC2131 sleep interval to n.
+                        This can be used with -DBACKOFF_LIMIT=0 to get a small
+                        and constant (predictable) retry interval for embedded
+                        devices. This is to achieve short boot delays if both
+                        the DHCP Server and the embedded device will be powered
+                        on the same time. Otherwise if the DHCP server is ready
+                        the client could sleep the next exponentially timeout,
+                        e.g. 70 seconds or more. This is not what you want.
+                        n should be a multiple of TICKS_PER_SEC (18).
+        Boot device options:
+        -DCAN_BOOT_DISK
+                        Can boot from floppy/hd if bootimage matches the
+                        pattern "/dev/fhsd*".
+        -DTRY_FLOPPY_FIRST
+                        If > 0, tries that many times to read the boot
+                        sector from a floppy drive before booting from
+                        ROM. If successful, does a local boot.
+                        It assumes the floppy is bootable.
+                        Requires -DCAN_BOOT_DISK.
+        -DEMERGENCYDISKBOOT
+                        If no BOOTP server can be found, then boot from
+                        local disk. The accessibility of the TFTP server
+                        has no effect, though! So configure your BOOTP
+                        server properly. You should probably reduce
+                        MAX_BOOTP_RETRIES to a small number like 3.
+        Boot image options:
+        -DTAGGED_IMAGE
+                        Add tagged image kernel boot support (recommended).
+        -DAOUT_IMAGE
+                        Add a.out kernel boot support (generic).
+        -DELF_IMAGE
+                        Add generic ELF kernel boot support (recommended).
+        -DEL64F_IMAGE
+                        Add generic ELF64 kernel boot support (useful for > 4GB disks).
+        -DWINCE_IMAGE
+                        Add the ability to boot WINCE.... now only sis630 OK!
+        -DFREEBSD_PXEEMU
+                        Add the ability to boot PXE images... only FreeBSD supported
+        -DX86_BOOTSECTOR_IMAGE
+                        Add the ability to boot 512 byte x86 boot sectors
+        -DIMAGE_MULTIBOOT
+                        Add Multiboot image support (currently only
+                        for ELF images).
+                        Without this, generic ELF support is selected.
+        -DIMAGE_FREEBSD
+                        Add FreeBSD image loading support (requires at least
+                        -DAOUT_IMAGE and/or -DELF_IMAGE).
+        -DFREEBSD_KERNEL_ENV
+                        Pass in FreeBSD kernel environment
+        -DAOUT_LYNX_KDI
+                        Add Lynx a.out KDI support
+        -DMULTICAST_LEVEL1
+                        Support for sending multicast packets
+        -DMULTICAST_LEVEL2
+                        Support for receiving multicast packets
+        -DDOWNLOAD_PROTO_TFTP
+                        If defined, boots by TFTP (recommended).
+        -DDOWNLOAD_PROTO_NFS
+                        If defined, boots from a NFS mount and disables
+                        TFTP loading. Default is DOWNLOAD_PROTO_TFTP
+                        if neither is defined.
+        -DDOWNLOAD_PROTO_SLAM
+                        If defined, boots via Scalable Local Area Multicast.
+        -DDOWNLOAD_PROTO_TFTM
+                        If defined, enables booting via TFTP Multicast mode.
+        -DSAFEBOOTMODE
+                        Enables "Safe Boot Mode": Only boot images after verification
+                        with public-key-cryptography, this is WORK IN PROGRESS
+                        must be or'ed from one publickey storage method and
+                        one nbi-digest method value
+  = store key in code (safeboot_key.h)
+  = store key in ROM somewhere else (to do)
+= crypted digest in first 512 bytes -
+                            as bytes 446...509 (compatible with most NBIs!?)
+= crypted digest as ELF block (to do... Eric?)
+                        So for now, only valid mode is "0"
+        Console options:
+        -DCONSOLE_FIRMWARE
+                        Set for firmware/BIOS provided (default if nothing else is set).
+                        Normally this is shows up on your CRT.
+        -DCONSOLE_SERIAL
+                        Set for serial console.
+        -DCONSOLE_DUAL
+                        Both of the above
+        -DCOMCONSOLE
+                        Set port, e.g. 0x3F8.
+        -DCONSPEED
+                        Set speed, e.g. 57600.
+        -DCOMPARM
+                        Set Line Control Register value for data bits, stop
+                        bits and parity. See a National Semiconditor 8250/
+/16550 data sheet for bit meanings.
+                        If undefined, defaults to 0x03 = 8N1.
+        -DCOMPRESERVE
+                        Ignore COMSPEED and COMPARAM and instead preserve
+                        the com port parameters from the previous user
+                        of the com port.  Examples of previous user are a BIOS
+                        that implements console redirection, lilo and LinuxBIOS.
+                        This makes it trivial to keep the serial port
+                        speed setting in sync between multiple users.
+                        You set the speed in the first user and the
+                        rest follow along.
+        Obscure options you probably don't need to touch:
+        -DPOWERSAVE
+                        Halt the processor when waiting for keyboard input
+                        which saves power while waiting for user interaction.
+                        Good for compute clusters and VMware emulation.
+                        But may not work for all CPUs.
+        -DRELOCATE
+                        After starting etherboot relocate to the top
+                        of memory.  This allows loading fairly arbitrary
+                        rom images.  This doesn't work with a couple of
+                        drivers, e.g. lance.
+        BUS options:
+        -DCONFIG_PCI
+                        Include support for devices using the pci bus.
+        -DCONFIG_ISA
+                        Include support for devices using isa bus.
+</file>
+===== Security, 1 July 1997 =====
+Markus Gutschke, gutschk AT math PERIOD uni-muenster PERIOD de
+==== Introduction ====
+This documentation has been written and is copyrighted 1997 by Markus Gutschke <gutschk AT math PERIOD uni-muenster PERIOD de>. You are free to distribute this file as long as you do not change its contents. I appreciate comments and will consider them in future revisions. If you have any questions, comments, or suggestions, please also send carbon copies of your e-mail message to both Ken Yap <ken_yap AT users PERIOD sourceforge PERIOD net> and Gero Kuhlmann <gero AT gkminix PERIOD han PERIOD de>. I will happily include any of your extensions, but I would like to avoid the proliferation of different incompatible revisions of this document. If these conditions are a problem to you, then feel free to contact me.
+==== SCOPE OF THIS TEXT ====
+ Any computer that is either physically accessible or can remotely be contacted over a network is potentially threatened by attempts to circumvent its security measures. The PC architecture is especially insecure and using a BOOT-Prom can help preventing some of the more obvious attacks. On the other hand, it also enables some attacks that are not possible against machines that boot from local mass storage devices (floppy, harddisk, ...). As a general rule, you can assume that it is impossible to protect your system from all conceivable attacks, but you can try to minimize the chance of an attack, try to minimize the seriousness of the damage caused and try to help in detecting attacks at the earliest possible moment. This text discusses some of the issues involved and tries to raise awareness of security problems; it cannot provide generic solutions to all of these problems, but should help you in appreciating the need for proper administration and regular security updates.
+==== PC ARCHITECTURE ====
+The PC architecture was never designed with security considerations in mind. Running an operating system such as DOS or Windows, allows the user full control over the hardware. There are no effective measures for preventing him from modifying data on local mass storage devices, reading confidential data that is stored locally, installing trojan horses and programs that intercept user input, monitoring all data packets that are sent on the local ethernet segment, sending ethernet packages with faked authorization information, and a whole lot of other potentially dangerous actions.
+Modern operating systems and suitable hardware extensions make these attacks more difficult, but as long as the user can still launch arbitrary programs that have full hardware access, there is not much protection that can be achieved in this way. Therefore, the most important security measures are those that prevent a malicious user from executing programs from arbitrary external sources.
+The PC must be physically protected, so that there is no way of replacing the harddrive (either for reading its contents or for installing compromised software), installing a modified system BIOS (if your system has a Flash BIOS, then make sure that it is always write protected and that write protection actually works!), connecting it to a different network, removing extra hardware that offers security features, or performing some other hardware modification.
+If the PC offers exchangeable mass storage devices (floppy, ZIP drive, CD-ROM, ...), the system must be configured to never boot from these devices.
+This is not as easy as it might sound. Most motherboards come with a system BIOS which offers back-doors to their password. So configuring the BIOS to never boot from exchangeable devices, will not prevent any determined hacker from modifying this setting. These generically accepted passwords might not be known to your average users, but you can assume that even a poorly informed hacker will know about them. Besides, if your system allows for reading the contents of the CMOS memory chip (e.g. by starting a suitable DOS program such the debugger which ships with DOS), then the password can be computed from this data. While you should still make sure, that your BIOS has password protection, this is only to be considered as a mild deterrent.
+A more useful protection is achieved by installing extra firmware, which requires a password before booting from a local device. This firmware should be written in a way which prevents the system BIOS from disabling it. This is the default configuration for the "etherboot" BOOT-Prom, but it might still be circumvented, if your system BIOS allows for disabling certain memory areas from being scanned for ROMs. If this is the case, then complain to your system vendor and replace the machine; it is unsuitable for being used in a publically accessible place. Also, in a security conscious environment, there must be no way of escaping from the control of the BOOT-Prom; this means, that you must not enable the "-DEMERGENCYDISKBOOT" option when compiling the "etherboot" software and you must never offer an empty image name in the image menu (c.f. README.VendorTags). If you want to offer booting from a local device, then specify the full device name and either enable the "-DFLOPPY" option or store a boot image (as generated by "mknbi-blkdev") under this name on the TFTP server.
+It might be a good idea to install non-functional bootcode in the master boot record of your harddisk and install any locally required boot code in the boot sectors of the individual partitions. Both "etherboot" and "mknbi-blkdev" know how to boot from partitions such as "/dev/hda1" (first primary partion) or "/dev/hdb5" (first logical partion on the second harddrive).
+If you have the choice, then do not offer operating systems which come without effective password protection and virtualization. This basically rules out all of the following: DOS, Windows, Win95, ...
+You should be aware of the fact, that offering one "dangerous" operating system, makes all other operating systems vulnerable as well. A noteworthy example is the availability of tools which allow an arbitrary DOS user to read and modify the contents of a Linux harddisk partition (similar tools are supposedly available for accessing NT partions).
+==== PASSWORDS PROTECTED BOOT-PROMS ====
+Password protected BOOT-Proms are a considerable improvement over the standard security measures offered by the PC architecture, but they are still vulnerable to a variety of attacks. Most of these attacks are related to the weaknesses of the BOOTP and TFTP protocol and these issues are discussed in another section of text.
+As the BOOT-Prom cannot store the passwords locally, it has to request them from the BOOTP/TFTP server. The BOOTP and TFTP protocols do not allow for any elaborate challenge/response authorization scheme. Thus the BOOT-Prom requests the password from the server and subsequently compares it with the password as input by the user. As packets transmitted on the ethernet can easily be monitored, the server sends a MD5 message digest (as invented by Ron Rivest/"RSA Data Security, Inc.") of the actual password. The BOOT-Prom computes the MD5 value for the user input and compares these two values. It is generally believed that there is no way of computing a valid plain text from a known MD5 message digest, other than comparing it against all conceivable input texts. Thus, this approach is still vulnerable against dictionary attacks. You should aim for using long passwords (although, anything beyond 20 characters is unlikely to considerably improve the security of the password) which are not listed in any dictionary. Make sure that these passwords are memorized and not available in un-encrypted form. Replace the passwords regularly and do not offer more menu entries in the BOOTP data than are absolutely necessary.
+==== BOOTING DOS ====
+ If you have to offer DOS or a related operating system, then do not fool yourself into believing that you can install security software in one of its configuration files. All of these mechanisms can easily be avoided. In many cases, even average users can figure out how to do this.
+==== BOOTING LINUX ====
+ There are a variety of ways that allow for booting Linux in single user mode. The most common techniques involve passing a suitable option on the kernel command line (i.e. "single") or crashing the filesystem by power cycling the machine; this in turn will result in fsck being invoked at the next system start, which will sometimes drop you into single user mode.
+Some Linux distributions do not require a password when entering single user mode. While this makes system administration somewhat easier, it is a considerable security problem. Make sure, that your system does not suffer from it.
+For other security problems with running insecure programs under Linux or using poorly configured distributions, refer to the Usenet newsgroups, security mailing lists and choose a distribution whose manufacturer frequently releases security fixes. It is a fallacy to assume that the unavailability of patches implies the security and correctness of a software application; as a rule of thumb, a manufacturer who releases more patches than a different one, probably cares more about the security of your system than the latter. This also applies to operating systems other than Linux!
+==== ETHERNET AND ITS PROTOCOLS
+ The ethernet is extremely vulnerable to attacks from malicious users. Anybody who can gain direct access to an ethernet segment, can easily monitor all traffic and inject forged data. This is very dangerous, because many protocols transfer data either un-encoded or in easily decipherable form. Also, authorization is often based on the assumption that the return address or a session id can be trusted, but this is no longer true if users gain unlimited access to the ethernet; it does not really matter if this access is achieved by having physical control over part of the network or by running a compromised or inherently insecure operating system. There are various attacks from machines that are not directly connected to your ethernet segment, but the majority of them can be prevented by installing and maintaining a properly configured firewall. For more information, you should regularly monitor security related newsgroups and mailinglists.
+==== BOOTP/TFTP ====
+ BOOTP and TFTP offer almost no security whatsoever. They basically provide their information to anybody who asks and solely rely on the assumption that your network is configured to not make the server world-accessible. If you install BOOTP gateways, then this assumption is seriously violated. Also, TFTP server are usually accessible from just about everywhere. You can try to diminish the impact of this problem by blocking BOOTP and TFTP packets from leaving or entering your network segment, but this will never be a completely secure solution.
+Thus you should always assume that all of the files that your BOOTP and TFTP server offer are world readable. They must not contain any sensitive data. Also, the TFTP daemon must be configured to only allow access to selected files. Running it in a chroot'd environment might be a very good idea.
+The BOOTP protocol is vulnerable against somebody else impersonating as a BOOTP server. While security aware operating systems, prevent non-privileged users from starting their own BOOTP servers, other operating systems do not allow this. This means, if any of your users can launch an arbitrary program under an insecure operating system on an arbitrary machine connected to your ethernet segment, then they have full control over the BOOTP boot process.
+==== NFS ====
+ While NFS is very convenient for installing diskless machines, it provides almost no security. Data is transmitted unencrypted and authorization is solely based on the identity of IP addresses. Anybody who can forge ethernet packets, has full access over any data that is available via NFS. While there are protocol extension that try to address these shortcomings, I am not aware of any solution for Linux based machines. This means, you have to assume that all exported filesystems are freely read- and writable. Bear this in mind when deciding which data you intend to export.
+==== TELNET/RLOGIN ====
+ Telnet and rlogin do not usually come with any effective protection other than simple password schemes. Data and even the password is transmitted as plain text. There are commonly available programs that constantly monitor the network for packets that contains passwords. Fortunately, the security of these protocols can be vastly improved by replacing them with the Secure Shell protocoll (http://www.cs.hut.fi/ssh). Preferably, all telnet and rlogin servers and clients should be removed from all machines.
+==== THE X WINDOW SYSTEM ====
+ X provides some security when run over a network, but the scope of it is limited and exploits can easily be devised. At the very least, you should make sure that the xauth protocol is used as opposed to the vastly inferior xhost protocol. A better solution is provided by routing all X connections through a secure shell session. This does not only provide more reliable authentication, but it also encrypts all data.
+==== CONCLUSION ====
+ While this text cannot do more than barely scratch the surface, it should help you in locating some of the more vulnerable sub-systems of your networks and your computers. It does not aim for completeness, but if you think that there is a topic which should be mentioned or if you want to update an entry, then please to contact me.
+=====VendorTag extensions, 28 April 2001=====
+ Markus Gutschke, gutschk AT math PERIOD uni-muenster PERIOD de with changes by Ken Yap, ken_yap AT users PERIOD sourceforge PERIOD net
+This documentation has been written and is copyrighted 1996,97 by Markus Gutschke <gutschk AT math PERIOD uni-muenster PERIOD de>. You are free to distribute this file as long as you do not change its contents. I appreciate comments and will consider them in future revisions. If you have any questions, comments, or suggestions, please also send carbon copies of your e-mail message to both Ken Yap <ken_yap AT users PERIOD sourceforge PERIOD net> and Gero Kuhlmann <gero AT gkminix PERIOD han PERIOD de>. I will happily include any of your extensions, but I would like to avoid the proliferation of different incompatible revisions of this document. If these conditions are a problem to you, then feel free to contact me.
+RFC1533 allows for vendor-specific extensions to the BOOTP protocol. It defines that all tags in the range 128 thru 254 are set aside for site-specific extensions. Common implementations of DHCP daemons can assign arbitrary null-terminated character strings to these tags.
+This is a list of the tags that are currently used by Etherboot. Tag 128 and 129 are handled by Etherboot. The other tags are handled by an external menu program, generated using mkelf-menu. This is changed behaviour from 5.0, where the menuing code was part of Etherboot. As a general rule, you should never fill out any of the other tags, unless you positively know that your BOOT-Prom supports the extension or ignores this particular tag:
+TAG 128
+ this is a six-byte hexadecimal entry. The first four bytes have to be the magic number E4 45 74 68; if this magic cannot be found, then none of the other vendor tags are valid! The fifth byte is the major version number and the sixth byte is the minor version number of this protocol extension. The current version is 0.0; the BOOT-Prom can assume that incompatible changes increase the major version number. Mere extensions to the existing protocol, increase the minor version number. If the BOOT-Prom code has been written in a way that anticipates future extensions, then it is acceptable to honor the vendor tags even though, the minor version number does not match exactly. Before making a change, that requires updating the major version number, you should contact all of the persons that are listed at the top of this document.
+TAG 129
+ the BOOT-Prom uses this tag for passing a user-provided command line to Linux. Anything in this tag will be appended to the kernel parameters already in the boot image created by mkelf.
+TAG 160
+ a string that contains a colon separated list of "parameter=value" pairs. Currently, these parameters are only used to control the behavior of an interactive menu for selecting different boot images; future extensions are quite likely:
+timeout
+ after this many seconds, the default image will be loaded. If no 'timeout' has been set, then the program will wait indefinitely.
+default
+ either an integer 'n' in the range 0 thru 15 or 192 thru 207, selecting the default image. If 'n' is in the first range, it refers to the 'n'th menu entry; if it is in the later range, it refers to the entry with the tag number 'n'. This distinction is important, if the list of images contains gaps. If no value has been set, then the image with the lowest tag number will be the default image.
+TAGS 161 thru 174
+ these tags are currently unused, but they should be allocated for purposes that resemble the function of tag 160.
+TAG 175
+ the BOOT-Prom uses this tag for telling the DHCP server which NIC driver it is using. The DHCP server can then modify the "filename" field in the DHCPACK packet in order to direct the BOOT-Prom to download an appropriate kernel image.
+TAG 176
+ the BOOT-Prom uses this tag for telling the loaded operating system, which of the entries in tags 192 to 207 has been selected by the user. As this tag is used internally, the DHCP daemon must not assign any value to it!
+TAGS 177 thru 183
+ these tags are reserved for passing information from the BOOT-Prom to the boot image. Under no circumstances should the DHCP daemon assign any of these entries. The format of these parameters is yet to be discussed.
+TAGS 184 thru 191
+ up to eight zero-terminated character strings can be used for displaying a "message of the day". If you need to display more than eight lines, you can embed suitable CR/LF pairs. If you fully exploit that feature, you can display a complete 80x24 screen of information, but you should be aware that subsequent output might scroll part of a long message.
+ The BOOT-Prom can optionally be configured to interpret some ANSI escape sequences.
+ The ANSI emulation currently knows about these commands:
+  Display attributes
+    Code          Effect
+    <esc>[0m      normal text
+    <esc>[1m      high-intensity on
+    <esc>[21m     high-intensity off
+    <esc>[5m      blinking on
+    <esc>[25m     blinking off
+    <esc>[7m      reverse video on
+    <esc>[27m     reverse video off
+    <esc>[3xm     set foreground color:
+    <esc>[4xm     set background color. x can be:
+- black                   4 - blue
+- red                     5 - magenta
+- green                   6 - cyan
+- yellow                  7 - white
+    <esc>[=xh     set video mode
+- 40x25 mono     (text)  13 - 40x25 16colors (gfx)
+- 40x25 16colors (text)  14 - 80x25 16colors (gfx)
+- 80x25 mono     (text)  15 - 80x25 mono     (gfx)
+- 80x25 16colors (text)  16 - 80x25 16colors (gfx)
+- 40x25 4colors  (gfx)   17 - 80x30 mono     (gfx)
+- 40x25 mono     (gfx)   18 - 80x30 16colors (gfx)
+- 80x25 mono     (gfx)   19 - 40x25 256colors(gfx)
+  Cursor control
+    Code          Effect
+    <esc>[r;cH    move cursor to row r and column c
+    <esc>[r;cf    move cursor to row r and column c
+    <esc>[rA      move cursor up r rows
+    <esc>[rB      move cursor down r rows
+    <esc>[cC      move cursor right c columns
+    <esc>[cD      move cursor left c columns
+    <esc>[?7l     turn off line wrap
+    <esc>[?7h     turn on line wrap
+    <esc>[J       clear screen and home cursor
+    <esc>[K       clear to end of line
+    <esc>[s       save the cursor position
+    <esc>[u       return cursor to saved position
+  Extended features
+    Code          Effect
+    <esc>[a;b;c;d+<data>
+                  draw pixel data.  Use  one byte  per  pixel.
+                  Colors are encoded as  shown above.  In text
+                  mode, graphics is approximated by outputting
+                  suitable    characters.  Parameters   differ
+                  depending    on  the number    of parameters
+                  passed:
+                    cnt
+                      "cnt"  data  bytes follow. They  will be
+                      drawn to  the right of the last graphics
+                      position.
+                    rle;col
+                      the next  "rle"  pixels  have the  value
+                      "col". They will  be drawn to  the right
+                      of the last  graphics position.  No data
+                      bytes follow.
+                    x;y;cnt
+                      "cnt" data  bytes  follow. They  will be
+                      drawn relative to the top left corner of
+                      the text cursor with an offset of (x/y).
+                    x;y;rle;col
+                      the next "rle"   pixels have  the  value
+                      "col".  They will  be drawn  relative to
+                      the top  left corner of the  text cursor
+                      with an offset  of (x/y).  No data bytes
+                      follow
+                  you usually   do not  have   to enter  these
+                  values manually, but you  should use  a tool
+                  such as  "ppmtoansi" which  is  shipped with
+                  your BOOT-Prom or available from the contrib
+                  directory of the "etherboot" package.
+    <esc>[a;b;c;d-<data>
+                  same as above,   but pack pixels into  three
+                  bits. The first pixel is stored in the three
+                  most  significant  bits  of the  first  data
+                  byte.
+   Note that you usually have to specify any control characters directly (rather than in hex form) in your /etc/dhcpd.conf file.
+TAGS 192 thru 207
+ these tags define all of the valid boot images and override any settings that are given with the filename field in your /etc/dhcpd.conf. It is allowed to leave gaps in the list. This has an impact on how the default image will be selected.
+ All entries are of the form
+            label:server:gateway:filename:passwd:flags:cmdline
+   For future extensibility, it is permitted to append an arbitrary amount of other colon separated entries as long as the limit of 255 characters per tag is not exceeded. Non-existent entries can be left empty. This means that the default value for this particular entry will be used. Trailing colons can be omitted.
+label
+ this is the text string that is displayed to the user. It can contain arbitrary characters, except for a colon. Embedding arbitrary control characters is not recommended, but you might be able to include ANSI escape sequences (if enabled in the ROM) for changing text attributes as long as you restore the attributes at the end of the string. It probably does not make very much sense to leave this entry empty.
+server
+ (This field is no longer supported. Its contents will be ignored.)
+gateway
+ (This field is no longer supported. Its contents will be ignored.)
+filename
+ name of the boot image that has to be loaded by TFTP. If this entry is omitted, then the machine boots locally from disk. If enabled in the BOOT-Prom, you can specify pseudo-filenames for booting from a local blockdevice (floppy, harddisk, ...); these filenames have to match the pattern "/dev/[fh]d*". If the BOOT-Prom does not have support for these pseudo-filenames, you can still boot from blockdevices by storing an boot image as generated by mknbi-blkdev under the name of the desired blockdevice (symbolic links will do). In Etherboot 4.6.2 and later, a - in this field means use the filename specified in the BOOTP/DHCP reply. This saves on menu size.
+passwd
+ MD5 message digest of the password. If this entry is omitted, then no password is required for loading this image. Support for passwords is optional and might not be compiled into the ROM image. For generating the MD5 message digest, you can use freely available tools such as "md5sum". C.f. the flags entry for controlling the behavior of passwords.
+flags
+ flags are used for controlling some aspects of how the BOOT-Prom code behaves. All flags are a string of decimal digits followed by a letter; multiple flags can be concatenated. If this entry is omitted, then a default value of "1i1p" is assumed. Currently, these flags are defined:
+i
+ booting this image does not require a password; the contents of the password entry is ignored unless some other feature (such as the flag "2p") requires it.
+i
+ booting this image requires a password. If the password entry is omitted, or no password support is available in the BOOT-Prom, then this flag is ignored.
+p
+ the user cannot enter a command line for passing parameters to the loaded image, even if this feature has been enabled when compiling the BOOT-Prom. N.B. this does not affect the cmdline entry as described below!
+p
+ the user does not get prompted for passing parameters to the loaded image, but he can explicitly request the prompt (e.g. by pressing a modifier key while selecting an image from the menu). If the password entry is not omitted, then the password has to be entered. Both parameter passing and password validation can be disabled when compiling the BOOT-Prom.
+p
+ the user always gets prompted for passing parameters to the loaded image. If the password entry is present and password support has been enabled in the BOOT-Prom, then the password has to be entered.
+p
+ the user always gets prompted for passing parameters to the loaded image. No password is required.
+cmdline
+ the contents of this entry is appended to the end of tag 129 from the DHCP record, provided tag 129 exists. This feature is unaffected by the "p" flags. Passing parameters currently does not make sense for any operating system other than Linux and is silently ignored for other operating systems. As it is not legal to enter colons as part of an entry, you have to escape them by writing "~c" instead. This also means, that all tilde characters have to be escaped by writing "~~". As some DHCP daemons do not allow for entering a backslash in a character string, the escape sequence "~b" inserts a backslash character. Currently, all other escape sequences are undefined.
+ (This example has not yet been translated to DHCPD syntax, sorry.) For demonstration purposes, I attached an annotated excerpt from my "bootptab" illustrating some of these techniques. In the following the character sequence ESC should be replaced by the ASCII escape character. Also the 8-bit characters have been changed to 7-bit approximations due to SGML tool limitations. To get the original codes, use this table: top left corner, char 201 (decimal); horizontal bar, char 205; top right corner, char 187; vertical bar, char 186; bottom left corner, char 200; bottom right corner, char 188.
+#
+# The MOTD (message of the day) can contain arbitrary characters, that
+# the PC is capable of displaying.  Here we use 8bit characters for
+# drawing a border around the message; also we change the foreground
+# color to red (this assumes that the BOOT Prom has support for ANSI
+# escape sequences):
+#
+.motd:\
+        :T184="ESC[31m":\
+        :T185="+------------------------------------------------------+":\
+        :T186="| This is an experimental release of the new BOOT-Prom |":\
+        :T187="| code.  It supports a couple of  non-standard  vendor |":\
+        :T188="| extensions.                                          |":\
+        :T189="+------------------------------------------------------+":\
+        :T190="ESC[37m":
+#
+# Alternatively, the MOTD can be stored in an external file; this
+# requires that you enabled ANSI support in the BOOT Prom!  For more
+# advanced configurability, you should explore the feature of the
+# patched tftpd daemon (as available in the contrib directory) to
+# execute shell scripts and use the output as the file contents.
+#
+# .motd:\
+#       :T184="ESC[31mLoading message of the day...ESC[37mESC['/etc/motd'#":
+#
+#
+# We use the "template" feature of modern versions of "bootp" in order
+# to group common entries. Unfortunately, you cannot use more than one
+# "tc" entry per (pseudo-) host.  Pseudo hostnames should begin with a
+# leading period character.
+#
+# All entries are kept as generic as possible.  This ensures that they
+# will keep working even when the network topology is changed. Leaving
+# the server IP address and the gateway IP address empty, should
+# ensure that booting works even when we go thru "bootpgw" gateways.
+#
+# "Technicolor" special effects are achieved by changing the
+# foreground text color of the individual labels. You could even embed
+# small icons after switching to graphics mode. C.f. "linux-logo.ansi"
+# for an example; this will not work, if your BOOT Prom does not have
+# support for ANSI escape sequences.
+#
+# Passing boot-time parameters to the Linux kernel, requires the
+# password "Penguin".
+#
+# Booting from the local disk requires the password "Joshua". If the
+# BOOT-Prom does not have support for booting from local block devices
+# (floppy, harddrive, ...), then you can either omit the filename
+# (c.f. README.Security for potential security problems) or your TFTP
+# server has to provide a boot image that has been generated by
+# mknbi-blkdev.
+#
+.imagemenu:\
+        :tc=.motd:\
+        :T128=E44574680000:\
+        :T160="timeout=30:default=207:":\
+        :T192="ESC[32mLinux 2.0.27ESC[37m:::/tftpdir/image-linux:99625fa1cac27bb6a2b33b7638afe47:0i1p":\
+        :T193="ESC[33mDOS 6.2ESC[37m:::/tftpdir/image-dos":\
+        :T207="ESC[34mLocal DiskESC[37m:::/dev/hda:85b103482a20682da703aa388933a6d8":
+#
+# When using more than a handful of vendor parameters, we have to
+# specify an extension file "ef". If you are very careful, then it is
+# possible to use one extension file for several hosts. Don't forget
+# to run "bootpef" after editing the "bootptab", and make sure that
+# you "chroot" into the proper directory, if applicable.
+#
+.default:\
+        :tc=.imagemenu:\
+        :bf=tftpdir/image-rom:\
+        :hd=:\
+        :ht=ethernet:\
+        :sm=255.255.255.0:\
+        :vm=auto:\
+        :ef=extension.bootp:
+#
+# Ideally, hosts differ only with respect to their ethernet hardware
+# ID and IP number. We let the "bootpd" look up the correct IP number.
+#
+thalamus:tc=.default:ha=00400529C11B:ip=thalamus:
+cortex: :tc=.default:ha=0000C0531A24:ip=cortex:
+   Here is an example DHCP specification that uses an external menu program. It also illustrates the use of - in the filename portion of the menu options to eliminate needless repetition.
+# per host setup
+host 192.168.40.203 {
+        # MAC and IP addresses
+        hardware ethernet  00:60:08:0d:a9:84;
+        fixed-address 192.168.40.203;
+        # default file to boot, common append options, default menu selection and timeout
+        filename "/tftpboot/menu.nb";
+        option option-128 E4:45:74:68:00:00;
+        option option-129 "ramdisk_size=16000 vga=6";
+        option option-160 "timeout=10:default=192";
+        option option-184 "^[['/tftpboot/thinlinux/1.0-alpha-025/motd'#";
+        # menu selections, specify filename or "-" to use default filename specified above
+        option option-192 "test1:::-:::nfs=xterm";
+        option option-193 "test2:::-:::nfs=shell";
+        option option-194 "test3:::-:::nfs=other";
+    }
+   For ISC DHCPD 3.0 Beta 2 Patchlevel 18 and above the syntax above is no longer accepted and a new syntax is in operation according to this note in the Changelog:
+Use unparsable names for unknown options. WARNING: this will break any
+configuration files that use the option-nnn convention. If you want to
+continue to use this convention for some options, please be sure to
+write a definition, like this:
+option option-nnn code nnn = string;
+You can use a descriptive name instead of option-nnn if you like.

Trace:

Differences

Navigation

Search

Toolbox

QR Code