🚀 go-pugleaf

Archive-Name: linux/howto/ethernet/part2
Last-modified: 2 Jul 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The Linux Ethernet HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <gregh@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Paul Gortmaker <Paul.Gortmaker@anu.edu.au>.

- --- BEGIN Linux Ethernet HOWTO part 2/3 ---

  There is some technical information available on the i82586 in
  ``Programming the Intel Chips'' and also in the source code for the
  driver `eexpress.c'. Don't be afraid to read it. ;-)


  3.18.2.  Ether Express PRO/10


  Status -- Semi-Supported

  Bao Chau Ha has written a driver for these cards that is scheduled to
  go into the 1.3.x kernels. It may also work with some of the Compaq
  built-in ethernet systems that are based on the i82595 chip. If you
  want to try the driver out now, you can e-mail Bao on
  bao@saigon.async.com and ask for it.

  3.18.3.  Ether Express PRO/100


  Status -- Not Supported

  These PCI and EISA cards use a different chip that the PRO/10 cards
  do. Bao is currently trying to get a datasheet out of Intel without
  having to sign a NDA. Good Luck!


  3.19.  LinkSys



  3.19.1.  LinkSys PCMCIA Adaptor


  Status -- Supported

  This is supposed to be a re-badged DE-650. See the information on the
  DE-650 in ``DE-650''.


  3.20.  Microdyne



  3.20.1.  Microdyne Exos 205T


  Status -- Semi-Supported

  Another i82586 based card. Dirk Niggemann dabn100@hermes.cam.ac.uk has
  written a driver that he classes as ``pre-alpha'' that he would like
  people to test. Mail him for more details.


  3.21.  Mylex


  Mylex can be reached at the following numbers, in case anyone wants to
  ask them anything.


          MYLEX CORPORATION, Fremont
          Sales:  800-77-MYLEX, (510) 796-6100
          FAX:    (510) 745-8016.




  3.21.1.  Mylex LNP101


  Status -- Supported

  This is a PCI card that is based on DEC's 21040 chip.  It is
  selectable between 10BaseT, 10Base2 and 10Base5 output.  The LNP101
  card has been verified to work with the generic 21040 driver.

  See the section on the 21040 chip (``DEC 21040'') for more
  information.




  3.21.2.  Mylex LNP104


  Status -- Not Supported

  The LNP104 uses the DEC 21050 chip to deliver four independent 10BaseT
  ports. It may work with 21040 drivers, but nobody has tried yet.


  3.21.3.  Mylex M390B EISA


  Status -- Not Supported

  Russ writes that "...it's a fairly vanilla 8390-based adapter.  Only
  really tricky thing is that, like the Interlan es3210, you MUST do
  only 32-bit transfers to/from the board.  Look at the Crynwr packet
  driver and try making the changes yourself...''


  3.22.  Novell Ethernet, NExxxx and associated clones.


  The prefix `NE' came from Novell Ethernet. Novell followed the
  cheapest NatSemi databook design and sold the manufacturing rights
  (spun off?) Eagle, just to get reasonably-priced ethercards into the
  market. (The now ubiquitous NE2000 card.)


  3.22.1.  NE1000, NE2000


  Status -- Supported

  The now-generic name for a bare-bones design around the NatSemi 8390.
  They use programmed I/O rather than shared memory, leading to easier
  installation but slightly lower performance and a few problems. Again,
  the savings of using an 8 bit NE1000 over the NE2000 are only
  warranted if you expect light use. Some recently introduced NE2000
  clones use the National Semiconductor `AT/LANTic' 83905 chip, which
  offers a shared memory mode similar to the 8013 and EEPROM or software
  configuration. Some problems can arise with poor NE2000 clones. See
  ``Problems with...'', and ``Poor NE2000 Clones'' In general it is not
  a good idea to put a NE2000 clone at I/O address 0x300 because nearly
  every device driver probes there at boot. Some poor NE2000 clones
  don't take kindy to being prodded in the wrong areas, and will respond
  by locking your machine.

  Donald has written a NE2000 diagnostic program, but it is still
  presently in alpha test. (ne2k) See ``Diagnostic Programs'' for more
  information.


  3.22.2.  NE1500, NE2100


  Status -- Supported

  These cards use the original 7990 LANCE chip from AMD and are
  supported using the Linux lance driver. Newer NE2100 clones use the
  updated PCnet/ISA chip from AMD.

  Some earlier versions of the lance driver had problems with getting
  the IRQ line via autoIRQ from the original Novell/Eagle 7990 cards.
  Hopefully this is now fixed.  If not, then specify the IRQ via LILO,
  and let us know that it still has problems.
  DMA selection and chip numbering information can be found in ``AMD
  LANCE''.

  More technical information on LANCE based cards can be found in
  ``Notes on AMD...''


  3.22.3.  NE3200


  Status -- Not Supported

  This card uses a lowly 8MHz 80186, and hence you are better off using
  a cheap NE2000 clone. Even if a driver was available, the NE2000 card
  would most likely be faster.


  3.23.  Pure Data



  3.23.1.  PDUC8028, PDI8023


  Status -- Supported

  The PureData PDUC8028 and PDI8023 series of cards are reported to
  work, thanks to special probe code contributed by Mike Jagdis
  jaggy@purplet.demon.co.uk. The support is integrated with the WD
  driver.


  3.24.  Racal-Interlan



  3.24.1.  NI52**


  Status -- Semi-Supported

  Michael Hipp has written a driver for this card. It is included in the
  standard kernel as an `alpha' driver. Michael would like to hear
  feedback from users that have this card. See ``Alpha Drivers'' for
  important information on using alpha-test ethernet drivers with Linux.

  Michael says that ``the internal sysbus seems to be slow. So we often
  lose packets because of overruns while receiving from a fast remote
  host.''

  This card also uses one of the Intel chips. See ``Programming the
  Intel Chips'' for more technical information.



  3.24.2.  NI65**


  Status -- Semi-Supported

  There is also a driver for the LANCE based NI6510, and it is also
  written by Michael Hipp. Again, it is also an `alpha' driver. For some
  reason, this card is not compatible with the generic LANCE driver. See
  ``Alpha Drivers'' for important information on using alpha-test
  ethernet drivers with Linux.

  3.25.  Sager



  3.25.1.  Sager NP943


  Status -- Semi-Supported

  This is just a 3c501 clone, with a different S.A. PROM prefix. I
  assume it is equally as brain dead as the original 3c501 as well.
  Kernels 1.1.53 and up check for the NP943 i.d. and then just treat it
  as a 3c501 after that. See ``3Com 3c501'' for all the reasons as to
  why you really don't want to use one of these cards.


  3.26.  Schneider & Koch



  3.26.1.  SK G16


  Status -- Supported

  This driver was included into the v1.1 kernels, and it was written by
  PJD Weichmann and SWS Bern. It appears that the SK G16 is similar to
  the NI6510, in that it is based on the first edition LANCE chip (the
  7990). Once again, I have no idea as to why this card won't work with
  the generic LANCE driver.


  3.27.  Western Digital / SMC (Standard Microsystems Corp.)


  The ethernet part of Western Digital has been bought by SMC.  One
  common mistake people make is that the relatively new SMC Elite Ultra
  is the same as the older SMC Elite16 models -- this is not the case.

  Here is how to contact SMC (not that you should need to.)

       SMC / Standard Microsystems Corp., 80 Arkay Drive, Hauppage,
       New York, 11788, USA.


  Technical Support via phone:

          800-992-4762 (USA)
          800-433-5345 (Canada)
          516-435-6250 (Other Countries)



  Literature requests:

          800-SMC-4-YOU (USA)
          800-833-4-SMC (Canada)
          516-435-6255  (Other Countries)



  Technical Support via E-mail:

          techsupt@ccmail.west.smc.com


  FTP Site:

          ftp.smc.com




  3.27.1.  WD8003, SMC Elite

  Status -- Supported

  These are the 8-bit versions of the card. The 8 bit 8003 is slightly
  less expensive, but only worth the savings for light use. Note that
  some of the non-EEPROM cards (clones with jumpers, or old old old
  wd8003 cards) have no way of reporting the IRQ line used. In this
  case, auto-irq is used, and if that fails, the driver silently assings
  IRQ 5.  Information regarding what the jumpers on old non-EEPROM
  wd8003 cards do can be found in conjunction with the SMC setup/driver
  disks stored on dorm.rutgers.edu in the directory
  /pub/novell/nic_drvs/. Note that some of the newer SMC `SuperDisk'
  programs will fail to detect the old EEPROM-less cards. The file
  SMCDSK46.EXE seems to be a good all-round choice. Also the jumper
  settings for old cards are in an ascii text file in the aforementioned
  archive. The latest (greatest?) version can be obtained from
  ftp.smc.com.

  As these are basically the same as their 16 bit counterparts (WD8013 /
  SMC Elite16), you should see the next section for more information.



  3.27.2.  WD8013, SMC Elite16


  Status -- Supported

  Over the years the design has added more registers and an EEPROM.
  Clones usually go by the `8013' name, and usually use a non-EEPROM
  (jumpered) design. This part of WD has been sold to SMC, so you'll
  usually see something like SMC/WD8013 or SMC Elite16 Plus (WD8013).
  Late model SMC cards will have two main PLCC chips on board; the SMC
  83c690 and the SMC 83c694.  The shared memory design makes the cards
  10-20 % faster, especially with larger packets. More importantly, from
  the driver's point of view, it avoids a few bugs in the programmed-I/O
  mode of the 8390, allows safe multi-threaded access to the packet
  buffer, and it doesn't have a programmed-I/O data register that hangs
  your machine during warm-boot probes.

  Non-EEPROM cards that can't just read the selected IRQ will attempt
  auto-irq, and if that fails, they will silently assign IRQ 10. (8 bit
  versions will assign IRQ 5)

  Also see ``8013 clones'' and ``8013 problems''.


  3.27.3.  SMC Elite Ultra


  Status -- Supported

  This ethercard is based on a new chip from SMC, with a few new
  features. While it has a mode that is similar to the older SMC
  ethercards, it's not compatible with the old WD80*3 drivers. However,
  in this mode it shares most of its code with the other 8390 drivers,
  while operating somewhat faster than a WD8013 clone.

  Since part of the Ultra looks like an 8013, the Ultra probe is
  supposed to find an Ultra before the wd8013 probe has a chance to
  mistakenly identify it.

  Std. as of 0.99pl14, and made possible by documentation and ethercard
  loan from Duke Kamstra. If you plan on using an Ultra with Linux send
  him a note of thanks to let him know that there are Linux users out
  there!

  Donald mentioned that it is possible to write a separate driver for
  the Ultra's `Altego' mode which allows chaining transmits at the cost
  of inefficient use of receive buffers, but that will probably not
  happen.

  Bus-Master SCSI host adaptor users take note: In the manual that ships
  with Interactive UNIX, it mentions that a bug in the SMC Ultra will
  cause data corruption with SCSI disks being run from an aha-154X host
  adaptor.  This will probably bite aha-154X compatible cards, such as
  the BusLogic boards, and the AMI-FastDisk SCSI host adaptors as well.

  SMC has acknowledged the problem occurs with Interactive, and older
  Windows NT drivers. It is a hardware conflict with early revisions of
  the card that can be worked around in the driver design. The current
  Ultra driver protects against this by only enabling the shared memory
  during data transfers with the card. Make sure your kernel version is
  at least 1.1.84, or that the driver version reported at boot is at
  least smc-ultra.c:v1.12 otherwise you are vulnerable.



  3.27.4.  SMC 8416 (EtherEZ)


  Status -- Supported

  This card uses SMC's 83c795 chip and supports the Plug 'n Play
  specification. It also has an SMC Ultra compatible mode, which allows
  it to be used with the Linux Ultra driver.  In this compatibility
  mode, it uses shared memory instead of programmed i/o. Be sure to set
  your card for this compatibility mode.

  Note that the EtherEZ specific checks were added to the SMC Ultra
  driver in 1.1.84, and hence earlier kernel versions will not handle
  these cards correctly.



  3.27.5.  SMC 8432 PCI (EtherPower)


  Status -- Supported

  These cards appear to be a basic DEC 21040 implementation, i.e. one
  big chip and a couple of transceivers. Donald has used one of these
  cards for his development of the generic 21040 driver. Thanks to Duke
  Kamstra, once again, for supplying a card to do development on.  See
  ``DEC 21040'' for more details on using one of these cards, and the
  current status of the driver.


  3.27.6.  SMC 3008


  Status -- Not Supported


  These 8 bit cards are based on the Fujitsu MB86950, which is an
  ancient version of the MB86965 used in the Linux at1700 driver. Russ
  says that you could probably hack up a driver by looking at the
  at1700.c code and his DOS packet driver for the Tiara card (tiara.asm)


  3.27.7.  SMC 3016


  Status -- Not Supported

  These are 16bit i/o mapped 8390 cards, much similar to a generic
  NE2000 card. If you can get the specifications from SMC, then porting
  the NE2000 driver would probably be quite easy.


  3.27.8.  SMC 9000


  Status -- Not Supported

  These cards are VLB cards based on the 91c92 chip. They are fairly
  expensive, and hence the demand for a driver is pretty low at the
  moment.


  3.28.  Xircom


  Another group that won't release documentation. No cards supported.
  Don't look for any support in the future unless they release their
  programming information. And this is highly unlikely, as they forbid
  you from even reverse- engineering their drivers. If you are already
  stuck with one, see if you can trade it off on some DOS (l)user.

  And if you just want to verify that this is the case, you can reach
  Xircom at 1-800-874-7875, 1-800-438-4526 or +1-818-878-7600.  They
  used to advertise that their products "work with all network operating
  systems", but have since stopped. Wonder why...


  3.28.1.  PE1, PE2, PE3-10B*


  Status -- Not Supported

  Not to get your hopes up, but if you have one of these parallel port
  adaptors, you may be able to use it in the DOS emulator with the
  Xircom-supplied DOS drivers. You will have to allow DOSEMU access to
  your parallel port, and will probably have to play with SIG (DOSEMU's
  Silly Interrupt Generator). I have no idea if this will work, but if
  you have any success with it, let me know, and I will include it here.


  3.29.  Zenith



  3.29.1.  Z-Note


  Status -- Supported

  The built-in Z-Note network adaptor is based on the Intel i82593 using
  two DMA channels. There is an (alpha?) driver available in the present
  kernel version. As with all notebook and pocket adaptors, it is under
  the `Pocket and portable adaptors' section when running make config.
  See ``Programming the Intel chips'' for more technical information.
  Also note that the IBM ThinkPad 300 is compatible with the Z-Note.


  3.30.  Znyx



  3.30.1.  Znyx ZX342 (DEC 21040 based)


  Status -- Supported

  You have a choice of two drivers for cards based on this chip. There
  is the DE425 driver written by David, and the generic 21040 driver
  that Donald has written.

  Note that as of 1.1.91, David has added a compile time option that may
  allow non-DEC cards (such as the Znyx cards) to work with this driver.
  Have a look at README.de4x5 for details.

  See ``DEC 21040'' for more information on these cards, and the present
  driver situation.


  4.  Clones of popular Ethernet cards.


  Due to the popular design of some cards, different companies will make
  `clones' or replicas of the original card. However, one must be
  careful, as some of these clones are not 100 % compatible, and can be
  troublesome. Some common problems with `not-quite-clones' are noted in
  ``the FAQ section''.

  This section used to have a listing of a whole bunch of clones that
  were reported to work, but seeing as nearly all clones will work, it
  makes more sense to list the ones that don't work 100 % .


  4.1.  Poor NE2000 Clones


  Here is a list of some of the NE-2000 clones that are known to have
  various problems. Most of them aren't fatal. In the case of the ones
  listed as `bad clones' -- this usually indicates that the cards don't
  have the two NE2000 identifier bytes. NEx000-clones have a Station
  Address PROM (SAPROM) in the packet buffer memory space.  NE2000
  clones have 0x57,0x57 in bytes 0x0e,0x0f of the SAPROM, while other
  supposed NE2000 clones must be detected by their SA prefix.

  Accton NE2000 -- might not get detected at boot, see ``ne2000
  problems''.

  Aritsoft LANtastic AE-2 -- OK, but has flawed error-reporting
  registers.

  AT-LAN-TEC NE2000 -- clone uses Winbond chip that traps SCSI drivers

  ShineNet LCS-8634 -- clone uses Winbond chip that traps SCSI drivers

  Cabletron E10**, E20**, E10**-x, E20**-x -- bad clones, but the driver
  checks for them. See ``E10**''.

  D-Link Ethernet II -- bad clones, but the driver checks for them. See
  ``DE-100 / DE-200''.
  DFI DFINET-300, DFINET-400 -- bad clones, but the driver checks for
  them. See ``DFI-300 / DFI-400''


  4.2.  Poor WD8013 Clones


  I haven't heard of any bad clones of these cards, except perhaps for
  some chamelion-type cards that can be set to look like a ne2000 card
  or a wd8013 card. There is really no need to purchase one of these
  `double-identity' cards anyway.


  5.  Cables, Coax, Twisted Pair

  If you are starting a network from scratch, it's considerably less
  expensive to use thin ethernet, RG58 co-ax cable with BNC connectors,
  than old-fashioned thick ethernet, RG-5 cable with N connectors, or
  10baseT, twisted pair telco-style cables with RJ-45 eight wire `phone'
  connectors. See ``Type of cable...'' for an introductory look at
  cables.

  Also note that the FAQ from comp.dcom.lans.ethernet has a lot of
  useful information on cables and such. Look in dorm.rutgers.edu for
  the file /pub/novell/info_and_docs/Ethernet.FAQ


  5.1.  Thin Ethernet (thinnet)


  Thin ethernet is the `ether of choice'. The cable is inexpensive. If
  you are making your own cables solid-core RG58A is $0.27/m. and
  stranded RG58AU is $0.45/m. Twist-on BNC connectors are < $2 ea., and
  other misc. pieces are similarly inexpensive. It is essential that you
  properly terminate each end of the cable with 50 ohm terminators, so
  budget $2 ea. for a pair. It's also vital that your cable have no
  `stubs' -- the `T' connectors must be attached directly to the
  ethercards. The only drawback is that if you have a big loop of
  machines connected together, and some bonehead breaks the loop by
  taking one cable off the side of his tee, the whole network goes down
  because it sees an infinite impedance (open circuit) instead of the
  required 50 ohm termination. Note that you can remove the tee piece
  from the card itself without killing the whole subnet, as long as you
  don't remove the cables from the tee itself. Of course this will
  disturb the machine that you pull the actual tee off of. 8-) And if
  you are doing a small network of two machines, you still need the tees
  and the 50 ohm terminators -- you can't just cable them together!



  5.2.  Twisted Pair


  Twisted pair networks require active hubs, which start around $200,
  and the raw cable cost can actually be higher than thinnet. They are
  usually sold using the claim that you can use your existing telephone
  wiring, but it's a rare installation where that turns out to be the
  case. The claim that you can upgrade to higher speeds is also suspect,
  as most proposed schemes use higher-grade (read $$) cable and more
  sophisticated termination ($$$) than you would likely install on
  speculation. New gizmos are floating around which allow you to daisy-
  chain machines together, and the like. For example, Farallon sells
  EtherWave adaptors and transceivers. This device allows multiple
  10baseT devices to be daisy-chained. They also sell a 3c509 clone that
  includes the EtherWave transceiver.  The drawback is that it's more
  expensive and less reliable than a cheap ($100-$150) mini-hub and
  another ethercard.  You probably should either go for the hub approach
  or switch over to 10base2 thinnet.

  On the other hand, hubs are rapidly dropping in price, all 100Mb/sec
  ethernet proposals use twisted pair, and most new business
  installations use twisted pair. (This is probably to avoid the problem
  with idiots messing with the BNC's as described above.)

  Also, Russ Nelson adds that `New installations should use Category 5
  wiring. Anything else is a waste of your installer's time, as 100Base-
  whatever is going to require Cat 5.'

  If you are only connecting two machines, it is possible to avoid using
  a hub, by swapping the Rx and Tx pairs (1-2 and 3-6).

  If you hold the RJ-45 connector facing you (as if you were going to
  plug it into your mouth) with the lock tab on the top, then the pins
  are numbered 1 to 8 from left to right. The pin usage is as follows:


          Pin Number              Assignment
          ----------              ----------
          1                       Output Data (+)
          2                       Output Data (-)
          3                       Input Data (+)
          4                       Reserved for Telephone use
          5                       Reserved for Telephone use
          6                       Input Data (-)
          7                       Reserved for Telephone use
          8                       Reserved for Telephone use



  Some cards, like the wd8013 can sense reversed polarity, and will
  adjust accordingly. Also note that 3 and 6 must be a twisted pair. If
  you make 3-4 a twisted pair, and 5-6 the other twisted pair, your
  cable may work for lengths less than a metre, but will fail miserably
  for longer lengths.

  Note that before 10BaseT was ratified as a standard, there existed
  other network formats using RJ-45 connectors, and the same wiring
  scheme as above. Examples are SynOptics's LattisNet, and AT&T's
  StarLAN.  In some cases, (as with early 3C503 cards) you could set
  jumpers to get the card to talk to hubs of different types, but in
  most cases cards designed for these older types of networks will not
  work with standard 10BaseT networks/hubs. (Note that if the cards also
  have an AUI port, then there is no reason as to why you can't use
  that, combined with an AUI to 10BaseT transceiver.)


  5.3.  Thick Ethernet

  Thick ethernet is mostly obsolete, and is usually used only to remain
  compatible with an existing implementation. You can stretch the rules
  and connect short spans of thick and thin ethernet together with a
  passive $3 N-to-BNC connector, and that's often the best solution to
  expanding an existing thicknet. A correct (but expensive) solution is
  to use a repeater in this case.

  6.  Software Configuration and Card Diagnostics


  In most cases, if the configuration is done by software, and stored in
  an EEPROM, you will usually have to boot DOS, and use the supplied DOS
  program to set the cards IRQ, I/O, mem_addr and whatnot. Besides,
  hopefully it is something you will only be setting once. For those
  that don't have the DOS utility available, note that a fair number of
  NIC setup/driver disks (e.g. 3Com, SMC/WD and Allied Telesis NIC's)
  are available from dorm.rutgers.edu in the directory
  /pub/novell/nic_drvs/ However, there are some cards for which Linux
  versions of the config utils exist, and they are listed here.

  Also, Donald has written a few small card diagnostic programs that run
  under Linux. Most of these are a result of debugging tools that he has
  created while writing the various drivers. Don't expect fancy menu-
  driven interfaces. You will have to read the source code to use most
  of these. Even if your particular card doesn't have a corresponding
  diagnostic, you can still get lots of information just by typing cat
  /proc/net/dev -- assuming that your card was at least detected at
  boot.

  In either case, you will have to run most of these programs as root
  (to allow I/O to the ports) and you probably want to shut down the
  ethercard before doing so by typing ifconfig eth0 down (Note: replace
  eth0 with atp0 or whatever when appropriate.)


  6.1.  Configuration Programs for Ethernet Cards


  For people with wd80x3 cards, there is the program wdsetup which can
  be found in wdsetup-0.6a.tar.gz on Linux ftp sites.  I am not sure if
  it is being actively maintained or not, as it has not been updated for
  quite a while. If it works fine for you then great, if not, use the
  DOS version that you should have got with your card. If you don't have
  the DOS version, you will be glad to know that the SMC setup/driver
  disks are available at the dorm.rutgers.edu site mentioned above.  Of
  course, you have to have an EEPROM card to use this utility.  Old, old
  wd8003 cards, and some wd8013 clones use jumpers to set up the card
  instead.

  The Digital EtherWorks 3 card can be configured in a similar fashion
  to the DOS program NICSETUP.EXE. David C. Davies wrote this and other
  tools for the EtherWorks 3 in conjunction with the driver. Look on
  sunsite.unc.edu in the directory /pub/linux/system/Network/management
  for the file that is named ewrk3tools-X.XX.tar.gz.

  Some Nat Semi DP83905 implementations (such as the AT/LANTIC and the
  NE2000+) are software configurable. (Note that this card can also
  emulate a wd8013!) You can get the file /pub/linux/setup/atlantic.c
  from Donald's ftp server, cesdis.gsfc.nasa.gov to configure this card.
  Be careful when configuring NE2000+ cards, as you can give them bad
  setting values which will require you to open the case and switch a
  jumper to force it back to sane settings.

  The 3Com Etherlink III family of cards (i.e. 3c5x9) can be configured
  by using another config utility from Donald.  You can get the file
  /pub/linux/setup/3c5x9setup.c from Donald's ftp server,
  cesdis.gsfc.nasa.gov to configure these cards. (Note that the DOS
  3c5x9B config utility may have more options pertaining to the new
  ``B'' series of the Etherlink III family.)




  6.2.  Diagnostic Programs for Ethernet Cards


  Any of the diagnostic programs that Donald has written can be obtained
  from this URL.


  Ethercard Diagnostics
  (http://cesdis.gsfc.nasa.gov/pub/linux/diag/diagnostic.html)

  Allied Telesis AT1700 -- look for the file /pub/linux/diag/at1700.c on
  cesdis.gsfc.nasa.gov.

  Cabletron E21XX -- look for the file /pub/linux/diag/e21.c on
  cesdis.gsfc.nasa.gov.

  HP PCLAN+ -- look for the file /pub/linux/diag/hp+.c on
  cesdis.gsfc.nasa.gov.

  Intel EtherExpress -- look for the file /pub/linux/diag/eexpress.c on
  cesdis.gsfc.nasa.gov.

  NE2000 cards -- look for the file /pub/linux/diag/ne2k.c on
  cesdis.gsfc.nasa.gov.

  RealTek (ATP) Pocket adaptor -- look for the file /pub/linux/diag/atp-
  diag.c on cesdis.gsfc.nasa.gov.

  All Other Cards -- try typing cat /proc/net/dev and see what useful
  info the kernel has on the card in question.


  7.  Technical Information


  For those who want to play with the present drivers, or try to make up
  their own driver for a card that is presently unsupported, this
  information should be useful. If you do not fall into this category,
  then perhaps you will want to skip this section.


  7.1.  Probed Addresses


  While trying to determine what ethernet card is there, the following
  addresses are autoprobed, assuming the type and specs of the card have
  not been set in the kernel. The file names below are in
  /usr/src/linux/drivers/net/


  ______________________________________________________________________
          3c501.c         0x280, 0x300
          3c503.c:        0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
          3c505.c:        0x300, 0x280, 0x310
          3c507.c:        0x300, 0x320, 0x340, 0x280
          3c509.c:        Special ID Port probe
          apricot.c       0x300
          at1700.c:       0x300, 0x280, 0x380, 0x320, 0x340, 0x260, 0x2a0, 0x240
          atp.c:          0x378, 0x278, 0x3bc
          depca.c         0x300, 0x200
          de600.c:        0x378
          de620.c:        0x378
          eexpress.c:     0x300, 0x270, 0x320, 0x340
          hp.c:           0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
          hp-plus.c       0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340
          lance.c:        0x300, 0x320, 0x340, 0x360
          ne.c:           0x300, 0x280, 0x320, 0x340, 0x360
          ni52.c          0x300, 0x280, 0x360, 0x320, 0x340
          ni65.c          0x300, 0x320, 0x340, 0x360
          smc-ultra.c:    0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380
          wd.c:           0x300, 0x280, 0x380, 0x240
  ______________________________________________________________________

  There are some NE2000 clone ethercards out there that are waiting
  black holes for autoprobe drivers. While many NE2000 clones are safe
  until they are enabled, some can't be reset to a safe mode.  These
  dangerous ethercards will hang any I/O access to their `dataports'.
  The typical dangerous locations are:

  ______________________________________________________________________
          Ethercard jumpered base     Dangerous locations (base + 0x10 - 0x1f)
                  0x300 *                         0x310-0x317
                  0x320                           0x330-0x337
                  0x340                           0x350-0x357
                  0x360                           0x370-0x377
  ______________________________________________________________________



  * The 0x300 location is the traditional place to put an ethercard, but
  it's also a popular place to put other devices (often SCSI
  controllers). The 0x320 location is often the next one chosen, but
  that's bad for for the AHA1542 driver probe. The 0x360 location is
  bad, because it conflicts with the parallel port at 0x378.  If you
  have two IDE controllers, or two floppy controlers, then 0x360 is also
  a bad choice, as a NE2000 card will clobber them as well.

  Note that kernels > 1.1.7X keep a log of who uses which i/o ports, and
  will not let a driver use i/o ports registered by an earlier driver.
  This may result in probes silently failing.  You can view who is using
  what i/o ports by typing cat /proc/ioports if you have the proc
  filesystem enabled.

  To avoid these lurking ethercards, here are the things you can do:


  o  Probe for the device's BIOS in memory space. This is easy and
     always safe, but it only works for cards that always have BIOSes,
     like primary SCSI controllers.

  o  Avoid probing any of the above locations until you think you've
     located your device. The NE2000 clones have a reset range from
     <base>+0x18 to <base>+0x1f that will read as 0xff, so probe there
     first if possible. It's also safe to probe in the 8390 space at
     <base>+0x00 - <base>+0x0f, but that area will return quasi-random
     values

  o  If you must probe in the dangerous range, for instance if your
     target device has only a few port locations, first check that there
     isn't an NE2000 there. You can see how to do this by looking at the
     probe code in /usr/src/linux/net/inet/ne.c

  o  Use the `reserve' boot time argument to protect volatile areas from
     being probed. See the information on using boot time arguments with
     LILO in ``The reserve command''


  7.2.  Skeleton / prototype driver



  OK. So you have decided that you want to write a driver for the Foobar
  Ethernet card, as you have the programming information, and it hasn't
  been done yet. (...these are the two main requirements ;-) You can use
  the skeleton network driver that is provided with the Linux kernel
  source tree. It can be found in the file
  /usr/src/linux/drivers/net/skeleton.c as of 0.99pl15, and later.


  It's also very useful to look at the Crynwr (nee Clarkson) driver for
  your target ethercard, if it's available. Russ Nelson
  nelson@crynwr.com has been actively updating and writing these, and he
  has been very helpful with his code reviews of the current Linux
  drivers.


  7.3.  Driver interface to the kernel


  Here are some notes that may help when trying to figure out what the
  code in the driver segments is doing, or perhaps what it is supposed
  to be doing.


  ______________________________________________________________________
          int ethif_init(struct device *dev)
          {
              ...
                  dev->send_packet = &ei_send_packet;
                  dev->open = &ei_open;
                  dev->stop = &ei_close;
                  dev->hard_start_xmit = &ei_start_xmit;
                  ...
          }

          int ethif_init(struct device *dev)
  ______________________________________________________________________



  This function is put into the device structure in Space.c. It is
  called only at boot time, and returns `0' iff the ethercard `dev'
  exists.


  ______________________________________________________________________
          static int ei_open(struct device *dev)
          static int ei_close(struct device *dev)
  ______________________________________________________________________



  This routine opens and initializes the board in response to a socket
  ioctl() usually called by `ifconfig'. It is commonly stuffed into the
  `struct device' by ethif_init().

  The inverse routine is ei_close(), which should shut down the
  ethercard, free the IRQs and DMA channels if the hardware permits, and
  turn off anything that will save power (like the transceiver).


  ______________________________________________________________________
          static int ei_start_xmit(struct sk_buff *skb, struct device *dev)
                  dev->hard_start_xmit = &ei_start_xmit;
  ______________________________________________________________________



  This routine puts packets to be transmitted into the hardware. It is
  usually stuffed into the `struct device' by ethif_init().

  When the hardware can't accept additional packets it should set the
  dev->tbusy flag. When additional room is available, usually during a
  transmit-complete interrupt, dev->tbusy should be cleared and the
  higher levels informed with mark_bh(INET_BH).
  ______________________________________________________________________
              if (dev_rint(buffer, length, is_skb ? IN_SKBUFF : 0, dev))
                     stats->rx_dropped++;
  ______________________________________________________________________



  A received packet is passed to the higher levels using dev_rint().  If
  the unadorned packet data is in a memory buffer, dev_rint will copy it
  into a `skbuff' for you. Otherwise a new skbuff should be kmalloc()ed,
  filled, and passed to dev_rint() with the IN_SKBUFF flag.


  ______________________________________________________________________
          int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
  ______________________________________________________________________



  Gives you a socket recieving every protocol type. Do recvfrom() calls
  to it and it will fill the sockaddr with device type in sa_family and
  the device name in the sa_data array. I don't know who originally
  invented SOCK_PACKET for Linux (its been in for ages) but its superb
  stuff.  You can use it to send stuff raw too (both only as root).



  7.4.  Interrupts and Linux


  There are two kinds of interrupt handlers in Linux: fast ones and slow
  ones. You decide what kind you are installing by the flags you pass to
  irqaction(). The fast ones, such as the serial interrupt handler, run
  with _all_ interrupts disabled. The normal interrupt handlers, such as
  the one for ethercard drivers, runs with other interrupts enabled.

  There is a two-level interrupt structure. The `fast' part handles the
  device register, removes the packets, and perhaps sets a flag.  After
  it is done, and interrupts are re-enabled, the slow part is run if the
  flag is set.

  The flag between the two parts is set by:


       mark_bh(INET_BH);


  Usually this flag is set within dev_rint() during a received-packet
  interrupt, and set directly by the device driver during a transmit-
  complete interrupt.

  You might wonder why all interrupt handlers cannot run in `normal
  mode' with other interrupts enabled. Ross Biro uses this scenario to
  illustrate the problem:


  o  You get a serial interrupt, and start processing it.  The serial
     interrupt is now masked.

  o  You get a network interrupt, and you start transferring a maximum-
     sized 1500 byte packet from the card.

  o  Another character comes in, but this time the interrupts are
     masked!


  The `fast' interrupt structure solves this problem by allowing
  bounded-time interrupt handlers to run without the risk of leaving
  their interrupt lines masked by another interrupt request.

  There is an additional distinction between fast and slow interrupt
  handlers -- the arguments passed to the handler. A `slow' handler is
  defined as


  ______________________________________________________________________

                  static void
                  handle_interrupt(int reg_ptr)
                  {
                      int irq = -(((struct pt_regs *)reg_ptr)->orig_eax+2);
                      struct device *dev = irq2dev_map[irq];
                  ...
  ______________________________________________________________________



  While a fast handler gets the interrupt number directly


  ______________________________________________________________________

                  static void
                  handle_fast_interrupt(int irq)
                  {
                  ...
  ______________________________________________________________________



  A final aspect of network performance is latency. The only board that
  really addresses this is the 3c509, which allows a predictive
  interrupt to be posted. It provides an interrupt response timer so
  that the driver can fine-tune how early an interrupt is generated.

  Alan Cox has some advice for anyone wanting to write drivers that are
  to be used with 0.99pl14 kernels and newer. He says:

  `Any driver intended for 0.99pl14 should use the new alloc_skb() and
  kfree_skbmem() functions rather than using kmalloc() to obtain a
  sk_buff. The new 0.99pl14 skeleton does this correctly. For drivers
  wishing to remain compatible with both sets the define
  `HAVE_ALLOC_SKB' indicates these functions must be used.

  In essence replace


       skb=(struct sk_buff *)kmalloc(size)


  with


       skb=alloc_skb(size)


  and


       kfree_s(skb,size)


  with


       kfree_skbmem(skb,size)  /* Only sk_buff memory though */


  Any questions should I guess be directed to me (Alan Cox) since I made
  the change.  This is a change to allow tracking of sk_buff's and
  sanity checks on buffers and stack behaviour. If a driver produces the
  message'File: ??? Line: ??? passed a non skb!' then it is probable the
  driver is not using the new sk_buff allocators.'



  7.5.  Programmed I/O vs. Shared Memory vs. DMA


  Ethernet is 10Mbs. (Don't be pedantic, 3Mbs and 100Mbs don't count.)
  If you can already send and receive back-to-back packets, you just
  can't put more bits over the wire. Every modern ethercard can receive
  back-to-back packets. The Linux DP8390 drivers come pretty close to
  sending back-to-back packets (depending on the current interrupt
  latency) and the 3c509 and AT1500 hardware has no problem at all
  automatically sending back-to-back packets.

  The ISA bus can do 5.3MB/sec (42Mb/sec), which sounds like more than
  enough. You can use that bandwidth in several ways:


  7.5.1.  Programmed I/O


  Pro: Doesn't use any constrained system resources, just a few I/O
  registers, and has no 16M limit.

  Con: Usually the slowest transfer rate, the CPU is waiting the whole
  time, and interleaved packet access is usually difficult to
  impossible.


  7.5.2.  Shared memory


  Pro: Simple, faster than programmed I/O, and allows random access to
  packets.

  Con: Uses up memory space (a big one for DOS users, only a minor issue
  under Linux), and it still ties up the CPU.


  7.5.3.  Slave (normal) Direct Memory Access


  Pro: Frees up the CPU during the actual data transfer.

  Con: Checking boundary conditions, allocating contiguous buffers, and
  programming the DMA registers makes it the slowest of all techniques.
  It also uses up a scarce DMA channel, and requires aligned low memory
  buffers.


  7.5.4.  Master Direct Memory Access (bus-master)


  Pro: Frees up the CPU during the data transfer, can string together
  buffers, can require little or no CPU time lost on the ISA bus.
  Con: Requires low-memory buffers and a DMA channel. Any bus-master
  will have problems with other bus-masters that are bus-hogs, such as
  some primitive SCSI adaptors. A few badly-designed motherboard
  chipsets have problems with bus-masters. And a reason for not using
  any type of DMA device is using a Cyrix 486 processor designed for
  plug-in replacement of a 386: these processors must flush their cache
  with each DMA cycle. (This includes the Cx486DLC, Ti486DLC, Cx486SLC,
  Ti486SLC, etc.)


  7.6.  Programming the Intel chips (i82586 and i82593)


  These chips are used on a number of cards, namely the 3c507 ('86), the
  Intel EtherExpress 16 ('86), Microdyne's exos205t ('86), the Z-Note
  ('93), and the Racal-Interlan ni5210 ('86).

  Russ Nelson writes: `Most boards based on the 82586 can reuse quite a
  bit of their code.  More, in fact, than the 8390-based adapters. There
  are only three differences between them:


  o  The code to get the Ethernet address,

  o  The code to trigger CA on the 82586, and

  o  The code to reset the 82586.

  The Intel EtherExpress 16 is an exception, as it I/O maps the 82586.
  Yes, I/O maps it. Fairly clunky, but it works.

  Garrett Wollman did an AT&T driver for BSD that uses the BSD
  copyright. The latest version I have (Sep '92) only uses a single
  transmit buffer. You can and should do better than this if you've got
  the memory. The AT&T and 3c507 adapters do; the ni5210 doesn't.

  The people at Intel gave me a very big clue on how you queue up
  multiple transmit packets. You set up a list of NOP-> XMIT-> NOP->
  XMIT-> NOP-> XMIT-> beginning) blocks, then you set the `next' pointer
  of all the NOP blocks to themselves. Now you start the command unit on
  this chain. It continually processes the first NOP block. To transmit
  a packet, you stuff it into the next transmit block, then point the
  NOP to it. To transmit the next packet, you stuff the next transmit
  block and point the previous NOP to it. In this way, you don't have to
  wait for the previous transmit to finish, you can queue up multiple
  packets without any ambiguity as to whether it got accepted, and you
  can avoid the command unit start-up delay.'


  7.7.  Technical information from 3Com


  If you are interested in working on drivers for 3Com cards, you can
  get technical documentation from 3Com. Cameron has been kind enough to
  tell us how to go about it below:

  3Com's Ethernet Adapters are documented for driver writers in our
  `Technical References' (TRs). These manuals describe the programmer
  interfaces to the boards but they don't talk about the diagnostics,
  installation programs, etc that end users can see.

  The Network Adapter Division marketing department has the TRs to give
  away. To keep this program efficient, we centralized it in a thing
  called `CardFacts.' CardFacts is an automated phone system. You call
  it with a touch-tone phone and it faxes you stuff. To get a TR, call
  CardFacts at 408-727-7021. Ask it for Developer's Order Form, document
  number 9070. Have your fax number ready when you call. Fill out the
  order form and fax it to 408-764-5004.  Manuals are shipped by Federal
  Express 2nd Day Service.

  If you don't have a fax and nobody you know has a fax, really and
  truly, then send mail to Terry_Murphy@3Mail.3Com.com and tell her
  about your problem.  PLEASE use the fax thing if you possibly can.

  After you get a manual, if you still can't figure out how to program
  the board, try our `CardBoard' BBS at 1-800-876-3266, and if you can't
  do that, write Andy_Chan@3Mail.3com.com and ask him for alternatives.
  If you have a real stumper that nobody has figured out yet, the fellow
  who needs to know about it is Steve_Lebus@3Mail.3com.com.

  There are people here who think we are too free with the manuals, and
  they are looking for evidence that the system is too expensive, or
  takes too much time and effort. That's why it's important to try to
  use CardFacts before you start calling and mailing the people I named
  here.

  There are even people who think we should be like Diamond and Xircom,
  requiring tight `partnership' with driver writers to prevent poorly
  performing drivers from getting written. So far, 3Com customers have
  been really good about this, and there's no problem with the level of
  requests we've been getting. We need your continued cooperation and
  restraint to keep it that way.

  Cameron Spitzer, 408-764-6339 3Com NAD Santa Clara work:
  camerons@nad.3com.com home: cls@truffula.sj.ca.us



  7.8.  Notes on AMD PCnet / LANCE Based cards


  The AMD LANCE (Local Area Network Controller for Ethernet) was the
  original offering, and has since been replaced by the `PCnet-ISA'
  chip, otherwise known as the 79C960.  A relatively new chip from AMD,
  the 79C960, is the heart of many new cards being released at present.
  Note that the name `LANCE' has stuck, and some people will refer to
  the new chip by the old name. Dave Roberts of the Network Products
  Division of AMD was kind enough to contribute the following
  information regarding this chip:

  `As for the architecture itself, AMD developed it originally and
  reduced it to a single chip -- the PCnet(tm)-ISA -- over a year ago.
  It's been selling like hotcakes ever since.

  Functionally, it is equivalent to a NE1500. The register set is
  identical to the old LANCE with the 1500/2100 architecture additions.
  Older 1500/2100 drivers will work on the PCnet-ISA.  The NE1500 and
  NE2100 architecture is basically the same.  Initially Novell called it
  the 2100, but then tried to distinguish between coax and 10BASE-T
  cards. Anything that was 10BASE-T only was to be numbered in the 1500
  range. That's the only difference.

  Many companies offer PCnet-ISA based products, including HP, Racal-
  Datacom, Allied Telesis, Boca Research, Kingston Technology, etc.  The
  cards are basically the same except that some manufacturers have added
  `jumperless' features that allow the card to be configured in
  software. Most have not. AMD offers a standard design package for a
  card that uses the PCnet-ISA and many manufacturers use our design
  without change.  What this means is that anybody who wants to write
  drivers for most PCnet-ISA based cards can just get the data-sheet
  from AMD. Call our literature distribution center at (800)222-9323 and
  ask for the Am79C960, PCnet-ISA data sheet. It's free.
  A quick way to understand whether the card is a `stock' card is to
  just look at it. If it's stock, it should just have one large chip on
  it, a crystal, a small IEEE address PROM, possibly a socket for a boot
  ROM, and a connector (1, 2, or 3, depending on the media options
  offered). Note that if it's a coax card, it will have some transceiver
  stuff built onto it as well, but that should be near the connector and
  away from the PCnet-ISA.'

  There is also some info regarding the LANCE chip in the file lance.c
  which is included in the standard kernel.

  A note to would-be card hackers is that different LANCE
  implementations do `restart' in different ways. Some pick up where
  they left off in the ring, and others start right from the beginning
  of the ring, as if just initialised. This is a concern when setting
  the multicast list.


  7.9.  Multicast and Promiscuous Mode


  Another one of the things Donald has worked on is implementing
  multicast and promiscuous mode hooks.  All of the released (i.e. not
  ALPHA) ISA drivers now support promiscuous mode. There was a minor
  problem with 8390 based cards with capturing multicast packets, in
  that the promiscuous mode setting in 8390.c around line 574 should be
  0x18 and not 0x10. If you have an up to date kernel, this will already
  be fixed.

  Donald writes: `At first I was planning to do it while implementing
  either the /dev/* or DDI interface, but that's not really the correct
  way to do it. We should only enable multicast or promiscuous modes
  when something wants to look at the packets, and shut it down when
  that application is finished, neither of which is strongly related to
  when the hardware is opened or released.

  I'll start by discussing promiscuous mode, which is conceptually easy
  to implement. For most hardware you only have to set a register bit,
  and from then on you get every packet on the wire. Well, it's almost
  that easy; for some hardware you have to shut the board (potentially
  dropping a few packet), reconfigure it, and then re-enable the
  ethercard. This is grungy and risky, but the alternative seems to be
  to have every application register before you open the ethercard at
  boot-time.

  OK, so that's easy, so I'll move on something that's not quite so
  obvious: Multicast. It can be done two ways:


  1. Use promiscuous mode, and a packet filter like the Berkeley packet
     filter (BPF). The BPF is a pattern matching stack language, where
     you write a program that picks out the addresses you are interested
     in. Its advantage is that it's very general and programmable. Its
     disadvantage is that there is no general way for the kernel to
     avoid turning on promiscuous mode and running every packet on the
     wire through every registered packet filter. See ``The Berkeley
     Packet Filter'' for more info.


  2. Using the built-in multicast filter that most etherchips have.

  I guess I should list what a few ethercards/chips provide:




          Chip/card  Promiscuous  Multicast filter
          ----------------------------------------
          Seeq8001/3c501  Yes     Binary filter (1)
          3Com/3c509      Yes     Binary filter (1)
          8390            Yes     Autodin II six bit hash (2) (3)
          LANCE           Yes     Autodin II six bit hash (2) (3)
          i82586          Yes     Hidden Autodin II six bit hash (2) (4)





  1. These cards claim to have a filter, but it's a simple yes/no
     `accept all multicast packets', or `accept no multicast packets'.

  2. AUTODIN II is the standard ethernet CRC (checksum) polynomial. In
     this scheme multicast addresses are hashed and looked up in a hash
     table. If the corresponding bit is enabled, this packet is
     accepted. Ethernet packets are laid out so that the hardware to do
     this is trivial -- you just latch six (usually) bits from the CRC
     circuit (needed anyway for error checking) after the first six
     octets (the destination address), and use them as an index into the
     hash table (six bits -- a 64-bit table).


  3. These chips use the six bit hash, and must have the table computed
     and loaded by the host. This means the kernel must include the CRC
     code.


  4. The 82586 uses the six bit hash internally, but it computes the
     hash table itself from a list of multicast addresses to accept.

  Note that none of these chips do perfect filtering, and we still need
  a middle-level module to do the final filtering. Also note that in
  every case we must keep a complete list of accepted multicast
  addresses to recompute the hash table when it changes.

  My first pass at device-level support is detailed in the new outline
  driver skeleton.c

  It looks like the following:
























  ______________________________________________________________________
          #ifdef HAVE_MULTICAST
          static void set_multicast_list(struct device *dev, int num_addrs,
                           void *addrs);
          #endif
          .
          .

          ethercard_open() {
          ...
          #ifdef HAVE_MULTICAST
                  dev->set_multicast_list = &set_multicast_list;
          #endif
          ...

          #ifdef HAVE_MULTICAST
          /* Set or clear the multicast filter for this adaptor.
             num_addrs -- -1      Promiscuous mode, receive all packets
             num_addrs -- 0       Normal mode, clear multicast list
             num_addrs > 0        Multicast mode, receive normal and
                  MC packets, and do best-effort filtering.
           */
          static void
          set_multicast_list(struct device *dev, int num_addrs, void *addrs)
          {
          ...
  ______________________________________________________________________



  Any comments, criticism, etc. are welcome.'


  7.10.  The Berkeley Packet Filter (BPF)


  The general idea of the developers is that the BPF functionality
  should not be provided by the kernel, but should be in a (hopefully
  little-used) compatibility library.

  For those not in the know: BPF (the Berkeley Packet Filter) is an
  mechanism for specifying to the kernel networking layers what packets
  you are interested in. It's implemented as a specialized stack
  language interpreter built into a low level of the networking code. An
  application passes a program written in this language to the kernel,
  and the kernel runs the program on each incoming packet. If the kernel
  has multiple BPF applications, each program is run on each packet.

  The problem is that it's difficult to deduce what kind of packets the
  application is really interested in from the packet filter program, so
  the general solution is to always run the filter. Imagine a program
  that registers a BPF program to pick up a low data-rate stream sent to
  a multicast address.  Most ethernet cards have a hardware multicast
  address filter implemented as a 64 entry hash table that ignores most
  unwanted multicast packets, so the capability exists to make this a
  very inexpensive operation. But with the BFP the kernel must switch
  the interface to promiscuous mode, receive _all_ packets, and run them
  through this filter. This is work, BTW, that's very difficult to
  account back to the process requesting the packets.


  8.  Networking with a Laptop/Notebook Computer


  There are currently only a few ways to put your laptop on a network.
  You can use the SLIP code (and run at serial line speeds); you can buy
  one of the few laptops that come with a NE2000-compatible ethercard;
  you can get a notebook with a supported PCMCIA slot built-in; you can
  get a laptop with a docking station and plug in an ISA ethercard; or
  you can use a parallel port Ethernet adapter such as the D-Link
  DE-600.


  8.1.  Using SLIP


  This is the cheapest solution, but by far the most difficult. Also,
  you will not get very high transmission rates. Since SLIP is not
  really related to ethernet cards, it will not be discussed further
  here. See the NET-2 Howto.


  8.2.  Built in NE2000


  This solution severely limits your laptop choices and is fairly
  expensive. Be sure to read the specifications carefully, as you may
  find that you will have to buy an additional non-standard transceiver
  to actually put the machine on a network. A good idea might be to boot
  the notebook with a kernel that has ne2000 support, and make sure it
  gets detected and works before you lay down your cash.



  8.3.  PCMCIA Support


  As this area of Linux development is fairly young, I'd suggest that
  you join the LAPTOPS mailing channel. See ``Mailing lists...''  which
  describes how to join a mailing list channel.

- --- END Linux Ethernet HOWTO part 2/3 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gregh@cc.gatech.edu for public key

iQCVAwUBL/hyMntNTo2suu5NAQEIvQP7BwkTET5rIUep+Zikr1DDIUO85l+Awp1z
0CFGF45vDtZfZ3MBwxSpgVxmtQZxrPTZOsMkQ9eyqbeihBw2RwYgsg+OvOJzwTmd
Mn4K7CCnrlYRMT7a6IvD66ZJ9B4n4UJkBYvl8ATkECYbqq5r7hg++glzjHbFuI17
ktiHnR4fRg0=
=URsG
-----END PGP SIGNATURE-----