2368 lines
97 KiB
Plaintext
2368 lines
97 KiB
Plaintext
From: Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
Newsgroups: comp.os.linux.announce,comp.os.linux.admin,comp.answers,news.answers
|
|
Subject: Linux Ethernet HOWTO (Part 1/2)
|
|
Keywords: Linux, Ethernet, TCP/IP, NET-2, network
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-Name: linux/howto/ethernet/part1
|
|
Last-Modified: 16 Mar 1994
|
|
|
|
Linux Ethernet HOWTO v1.0 -- Last updated Mar 16, 1994
|
|
=================================================================
|
|
|
|
-- covers changes up to and including Linux kernel v1.0
|
|
|
|
INDEX:
|
|
|
|
0 Introduction.
|
|
0.01 How do I use this Guide?
|
|
0.01 Disclaimer and Copyright
|
|
0.02 Questions already?
|
|
0.03 Related Documentation
|
|
0.04 New Versions of this Document
|
|
0.05 Feedback
|
|
|
|
1 What card should I buy for Linux?
|
|
1.01 Eight bit vs 16 bit
|
|
1.02 Low price Ethernet cards
|
|
1.03 Vendors and brands to avoid.
|
|
1.04 Type of cable that your card should support
|
|
|
|
2 Status of various Ethernet cards under Linux.
|
|
2.01 3Com
|
|
2.02 Western Digital / SMC
|
|
2.03 NExxxx
|
|
2.04 Hewlett Packard Cards
|
|
2.05 D-Link
|
|
2.06 Cabletron
|
|
2.07 Allied Telesis
|
|
2.08 Arcnet
|
|
2.09 Digital / DEC
|
|
2.10 Intel
|
|
2.11 PureData
|
|
2.12 Xircom
|
|
2.13 Zenith
|
|
2.14 Racal-Interlan
|
|
2.15 AMD LANCE (79C960)
|
|
2.16 AT-Lan-Tec / RealTek Pocket adaptor
|
|
2.17 Ansel
|
|
2.18 DFI
|
|
|
|
3 Clones of popular Ethernet cards.
|
|
3.01 WD80x3 Clones
|
|
3.02 NE2000 Clones
|
|
|
|
4 Cables, coax, twisted pairs etc.
|
|
4.01 Thin Ethernet (thinnet)
|
|
4.02 Twisted Pair
|
|
4.03 Thick Ethernet
|
|
|
|
5 Technical information.
|
|
5.01 Probed addresses
|
|
5.02 Skeleton / prototype driver
|
|
5.03 Driver interface to the kernel
|
|
5.04 Interrupts and linux
|
|
5.05 Programmed I/O vs. shared mem. vs slave/master DMA
|
|
5.06 Programming the Intel chips (i82586 and i82593)
|
|
5.07 Programming information from 3Com
|
|
5.08 Notes on AMD PCnet-ISA / LANCE Based cards (79C960)
|
|
5.09 Multicast and Promiscuous mode
|
|
5.10 The Berkeley Packet Filter (BPF)
|
|
5.11 Unresolved questions / concerns
|
|
|
|
6 Possible problems, questions and troubleshooting.
|
|
6.01 Problems with NE2000 (and clones)
|
|
6.02 Problems with WD80*3 cards
|
|
6.03 Problems with 3Com cards
|
|
|
|
7 Networking with a laptop computer.
|
|
7.01 Option 1 -- using SLIP
|
|
7.02 Option 2 -- Built in NE2000 compatible or PCMCIA Ethercard.
|
|
7.03 Option 3 -- ISA Ethercard in the docking station.
|
|
7.04 Option 4 -- Pocket / parallel port adaptors.
|
|
|
|
8 Frequently asked questions.
|
|
8.01 Just the FAQ's ma'am -- just the FAQ's.
|
|
|
|
9 Miscellaneous.
|
|
9.01 Bad Vendors
|
|
9.02 Closing
|
|
|
|
======================================================================
|
|
|
|
0. Introduction.
|
|
|
|
This is the Ethernet-HOWTO, which is a compilation of information
|
|
about which ethernet devices can be used for Linux, and how to
|
|
set them up.
|
|
|
|
This Ethernet-HOWTO is by:
|
|
Donald J. Becker <becker@super.org>
|
|
Paul Gortmaker <gpg109@rsphy1.anu.edu.au>
|
|
|
|
It covers what cards you should and shouldn't buy; how to set
|
|
them up, how to run more than one, and other common problems and
|
|
questions. It does *not* cover the software end of things, as that
|
|
is covered in the NET-2 HOWTO.
|
|
|
|
Other people who have contributed (directly or indirectly) are,
|
|
in alphabetical order:
|
|
|
|
Peter Bauer <pbauer@rnivh.rni.sub.org>
|
|
Ross Biro <bir7@leland.Stanford.EDU>
|
|
Alan Cox <iiitac@pyr.swan.ac.uk>
|
|
David C. Davies <davies@wanton.enet.dec.com>
|
|
Bjorn Ekwall <bj0rn@blox.se>
|
|
Charles Hedrick <hedrick@geneva.rutgers.edu>
|
|
Mike Jagdis <jaggy@purplet.demon.co.uk>
|
|
Duke Kamstra <kamstra@ccmail.west.smc.com>
|
|
Russell Nelson <nelson@crynwr.com>
|
|
Cameron Spitzer <camerons@NAD.3Com.com>
|
|
Dave Roberts <david.roberts@amd.com>
|
|
Glenn Talbott <gt@hprnd.rose.hp.com>
|
|
Miquel van Smoorenburg <miquels@cistron.nl.mugnet.org>
|
|
|
|
Many thanks to the above people, and all the other unmentioned
|
|
testers out there.
|
|
|
|
0.01 How Do I Use This Guide?
|
|
|
|
As this guide is getting bigger and bigger, you probably don't want
|
|
to spend the rest of your afternoon reading the whole thing. And you
|
|
don't *have* to read it all. If you haven't got an ethernet card, then
|
|
you will want to start with section one to see what you should buy,
|
|
and what you should avoid. If you have already got an ethernet card,
|
|
but are not sure if you can use it with Linux, then you will want to
|
|
read section two, which contains specific information on each
|
|
manufacturer, and their cards. If you are having trouble with your
|
|
card, then you will want to read the specific information about
|
|
your card in section two and the troubleshooting information in
|
|
section six. If you are interested in some of the technical aspects
|
|
of the device drivers, then you can find that information in
|
|
section 5.
|
|
|
|
0.01 Disclaimer and Copyright
|
|
|
|
This document is *not* gospel. However, it is probably the most
|
|
up to date info that you will be able to find. Nobody is responsible
|
|
for what happens to your hardware but yourself. If your ethercard
|
|
or any other hardware goes up in smoke (...nearly impossible!)
|
|
we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE
|
|
FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
|
|
INFORMATION INCLUDED IN THIS DOCUMENT.
|
|
|
|
This document is Copyright (c) 1994 by Donald Becker and
|
|
Paul Gortmaker. Permission is granted to make and distribute
|
|
verbatim copies of this manual provided the copyright notice
|
|
and this permission notice are preserved on all copies.
|
|
|
|
Permission is granted to copy and distribute modified versions
|
|
of this document under the conditions for verbatim copying,
|
|
provided that this copyright notice is included exactly as in
|
|
the original, and that the entire resulting derived work is
|
|
distributed under the terms of a permission notice identical
|
|
to this one.
|
|
|
|
Permission is granted to copy and distribute translations
|
|
of this document into another language, under the above
|
|
conditions for modified versions.
|
|
|
|
0.02 Questions already?
|
|
|
|
If you have questions about your ethernet card, please READ this
|
|
document first. You may also want to join the NET channel of the
|
|
Linux-activists mailing list by sending mail to
|
|
linux-activists-request@niksula.hut.fi
|
|
with the line
|
|
X-Mn-Admin: join NET
|
|
at the top of the message body (not the subject). If you want to
|
|
learn how to use the mailing channels, then send an empty message
|
|
to the above address, and you will get an instruction manual sent
|
|
back to you in a few hours. However, it is worth noting that the NET
|
|
channel is primarily used for discussion of the networking code, and
|
|
you may not see much discussion about a particular driver.
|
|
Furthermore keep in mind that the NET channel is for development
|
|
discussions only. General questions on how to configure your system
|
|
should be directed to comp.os.linux.help unless you are actively
|
|
involved in the development of part of the networking for Linux.
|
|
We ask that you *please* respect this general guideline for content.
|
|
You can safely bet that neither of the authors will respond to
|
|
any plea for help that *should* be posted to c.o.l.help, but is
|
|
inappropriately placed elsewhere.
|
|
|
|
0.03 Related Documentation
|
|
|
|
Much of this info came from saved postings from the comp.os.linux
|
|
groups, which shows that it is a valuable resource of information.
|
|
Other useful information came from a bunch of small files by Donald
|
|
himself. Some of these are found at /pub/linux/info on ftp.super.org
|
|
[192.31.192.1] Of course, if you are setting up an Ethernet card,
|
|
then you will want to read the NET-2 HOWTO so that you can actually
|
|
do something with it. ftp.super.org is the home of most alpha drivers
|
|
that are not presently in the kernel. And last but not least, the
|
|
contributions from the individuals and companies listed above are
|
|
greatly appreciated as well. Oh yeah, if you fancy yourself as
|
|
a bit of a hacker, you can always scrounge some additional info
|
|
from the driver source files as well. There is usually a paragraph
|
|
in there describing any important points.
|
|
|
|
0.04 New versions of this document
|
|
|
|
New versions of this document can be retrieved via anonymous
|
|
FTP from sunsite.unc.edu:/pub/Linux/docs/HOWTO/* and various
|
|
Linux ftp mirror sites. It will also be posted to the newsgroup
|
|
comp.os.linux.announce at a regular interval. Updates will be made
|
|
as new information / drivers becomes available. If this copy
|
|
that you are reading is more than 2 months old, it is either out of
|
|
date, or it means that I have been lazy and haven't updated it.
|
|
|
|
0.05 Feedback
|
|
|
|
Any corrections can be sent to one of us (gpg109@rsphysse.anu.edu.au
|
|
or becker@super.org) We will *attempt* to keep this up to date as
|
|
more drivers become available, and as the networking code matures.
|
|
|
|
1 What card should I buy for Linux?
|
|
|
|
For impatient users that just want a quick, cheap answer the
|
|
summary is: get 16 bit thinnet 8013 cards. For more detail as
|
|
to the who what where and why, read on.
|
|
|
|
1.01 Eight bit vs 16 bit
|
|
|
|
Unless you are a light user, or are confined to using the smaller
|
|
ISA slot, the use of the 8 bit cards like the wd8003 and the 3c503
|
|
is really not worth the cost savings. Get the 8013 or the 3c503/16
|
|
instead.
|
|
|
|
1.02 Low price Ethernet cards
|
|
|
|
I keep track of the current low-price vendors, just because it's
|
|
asked so often. Call AT-LAN-TEC at 301-948-7070. Ask for their
|
|
technical support person, "Vincent Bono". As with all purchases,
|
|
you should indicate you are buying this for a Linux system.
|
|
The last I checked the price for 10 NE2000s was $480, or $48 ea.!
|
|
NB: Their current NE2000 clone is a model that "traps" other
|
|
drivers that probe into their address space. AT-LAN-TEC also carries
|
|
a clone, non-EEPROM 8013 board for somewhat more, and a NE2100 clone.
|
|
Either is a better choice if the very lowest price isn't essential.
|
|
Also, SMC is offering an evaluation deal on their new Ultra cards,
|
|
and the word is that you can get one for $50. You can ask them
|
|
yourself by calling 1-800-SMC-4YOU in Canada and the USA.
|
|
|
|
The Allied Telesis AT1500 is offered at a good price by many vendors.
|
|
Even Inmac, known for their premium markup, has this card for under
|
|
$100.
|
|
|
|
1.03 Vendors and Brands to Avoid
|
|
|
|
These vendors have decided *not* to release programming information
|
|
about their products, without signing a non-disclosure agreement.
|
|
More information can be found in section two and 9.01. Hence it is
|
|
strongly advised that you avoid buying products offered from
|
|
these companies.
|
|
|
|
(1) Cabletron
|
|
(2) Xircom
|
|
|
|
These particular cards should be avoided, as they are obsolete.
|
|
The reasons as to why they have been classified as such can be
|
|
found in section 2 of this document.
|
|
|
|
(1) 3c501
|
|
(2) Arcnet
|
|
|
|
1.04 Type of cable that your card should support
|
|
|
|
Unless you have to conform to an existing network, you will want
|
|
to use thinnet or thin ethernet cable. This is the style with the
|
|
standard BNC connectors. See section 4 for other concerns with
|
|
different types of ethernet cable.
|
|
|
|
Most ethercards also come in a "Combo" version for only $10-$20 more.
|
|
These have both twisted pair and thinnet transceiver built-in,
|
|
allowing you to change your mind later.
|
|
|
|
2 Status of Various Ethernet Cards under Linux
|
|
|
|
The only thing that one needs to use an ethernet card with Linux
|
|
is the appropriate driver. For this, it is essential that the
|
|
manufacturer will release the technical programming information to
|
|
the general public without you (or anyone) having to sign your life
|
|
away. A good guide for the likelihood of getting documentation
|
|
(or, if you aren't writing code, the likelihood that someone
|
|
else will write that driver you really, really need) is the
|
|
availability of the Crynwr (nee Clarkson) packet driver. Russ
|
|
Nelson (see the acknowledgements in the intro.) runs this
|
|
operation, and has been very helpful in supporting the development
|
|
of drivers for Linux.
|
|
|
|
Given the documentation, you can write a driver for
|
|
your card and use it for Linux, at least in theory. Keep in
|
|
mind that some old hardware that was designed for XT type
|
|
machines will not function very well in a multitasking
|
|
environment such as Linux. Use of these will lead to major
|
|
problems if your network sees a reasonable amount of traffic.
|
|
|
|
Most cards come with drivers for MS-DOS interfaces such as
|
|
NDIS and ODI, but these are useless for Linux. Many people
|
|
have suggested directly linking them in or automatic
|
|
translation, but this is nearly impossible. The MS-DOS
|
|
drivers expect to be in 16 bit mode and hook into "software
|
|
interrupts", both incompatible with the Linux kernel. This
|
|
incompatibility is actually a feature, as some Linux drivers
|
|
are considerably better than their MS-DOS counterparts. The
|
|
"8390" series drivers, for instance, use ping-pong transmit
|
|
buffers, which are only now being introduced in the MS-DOS world.
|
|
|
|
Keep in mind that PC ethercards have the widest variety of
|
|
interfaces (shared memory, programmed I/O, bus-master, or slave
|
|
DMA) of any computer hardware for anything, and supporting a
|
|
new ethercard sometimes requires re-thinking most of the lower-level
|
|
networking code. (If you are interested in learning more about
|
|
these different forms of interfaces, see section 5)
|
|
|
|
Also, similar product numbers don't always indicate similar products.
|
|
For instance, the 3c50* product line from 3Com varies wildly
|
|
between different members.
|
|
|
|
Enough talk. Let's get down to the information you want.
|
|
|
|
2.01 3Com
|
|
|
|
Supported:
|
|
|
|
3c503, 3c503/16
|
|
3Com shared-memory ethercards. They also have a
|
|
programmed I/O mode that doesn't use the 8390
|
|
facilities (their engineers found too many bugs!)
|
|
It should be about the same speed as the same bus
|
|
width WD80x3, but I don't have a 16 bit version
|
|
to benchmark. Unless you are a light user, spend
|
|
the extra money and get the 16 bit model, as the
|
|
price difference isn't significant. The 3c503 does not
|
|
have "EEPROM setup", so the diagnostic/setup program
|
|
isn't needed before running the card with Linux. The
|
|
shared memory address of the 3c503 is set using jumpers
|
|
that are shared with the boot PROM address. This is
|
|
confusing to people familiar with other ISA cards,
|
|
where you always leave the jumper set to "disable"
|
|
unless you have a boot PROM.
|
|
|
|
The Linux 3c503 driver can also work with the 3c503
|
|
programmed-I/O mode, but this is slower and less
|
|
reliable than shared memory mode. Also, programmed-I/O
|
|
mode is not tested when updating the drivers, the
|
|
deadman (deadcard?) check code may falsely timeout on
|
|
some machines, and the probe for a 3c503 in
|
|
programmed-I/O mode is turned off by default in some
|
|
versions of the kernel. This was a panic reaction to
|
|
the general device driver probe explosion; the 3c503
|
|
shared memory probe is a safe read from memory, rather
|
|
than an extensive scan through I/O space. As of pl13,
|
|
the kernel has an I/O port registrar that makes I/O
|
|
space probes safer, (see section 5.1 for more info.)
|
|
and the programmed-I/O 3c503 probe has been re-enabled.
|
|
You still shouldn't use the programmed-I/O mode though,
|
|
unless you need it for MS-DOS compatibility.
|
|
|
|
The 3c503's IRQ line is set in software, with no hints
|
|
from an EEPROM. Unlike the MS-DOS drivers, the
|
|
Linux driver has capability to autoIRQ: it uses the
|
|
first available IRQ line in {5,2/9,3,4}, selected each
|
|
time the card is 'ifconfig'ed. (Older driver versions
|
|
selected the IRQ at boot time.) The ioctl() call
|
|
in 'ifconfig' will return EAGAIN if no IRQ line is
|
|
available at that time.
|
|
|
|
3c509
|
|
A fairly new card from 3Com. It's inexpensive and has
|
|
excellent performance for a non-bus-master design. The
|
|
drawbacks are that it _requires_ very low interrupt
|
|
latency, and it isn't rated for bus speeds greater than
|
|
8Mhz.
|
|
|
|
A working 3c509 driver was first included as an
|
|
alpha-test version in the 0.99pl13 kernel sources.
|
|
It is now in the standard kernel.
|
|
|
|
The 3c509 has a tiny Rx buffer, causing the driver to
|
|
occasionally drop a packet if interrupts are masked for
|
|
too long. To minimize this problem, the driver should
|
|
be completely rewritten to use predictive interrupts.
|
|
(Note: performance re-writes of working drivers are low
|
|
priority unless there is some particular incentive or
|
|
need.)
|
|
|
|
There is also an alpha version of a Linux 3c509
|
|
diagnostic and EEPROM setup program, but for now
|
|
users that don't like the defaults should use the
|
|
MS-DOS EEPROM setup program.
|
|
|
|
3c579
|
|
The EISA version of the 509. The current EISA version
|
|
uses the same 16 bit wide chip rather than a 32 bit
|
|
interface, so the performance increase isn't stunning.
|
|
The EISA probe code was added to 3c509.c for pl14.
|
|
We would be interested in hearing progress reports
|
|
from any 3c579 users. (Read the above 3c509
|
|
section for info on the driver.)
|
|
|
|
Cameron Spitzer writes:
|
|
"The 3C579 (Etherlink III EISA) should be configured
|
|
as an EISA card. The IO Base Address (window 0
|
|
register 6 bits 4:0) should be 1f, which selects EISA
|
|
addressing mode. Logic outside the ASIC decodes the
|
|
IO address s000, where s is the slot number. I don't
|
|
think it was documented real well. Except for its IO
|
|
Base Address, the '579 should behave EXACTLY like the
|
|
'509 (EL3 ISA), and if it doesn't, I want to hear
|
|
about it (at my work address).
|
|
|
|
I will leave it to the Real Programmers to suggest
|
|
the right hack to /usr/src/linux/net/inet/3c509.c to
|
|
take care of the EISA case.
|
|
|
|
(Note that the drivers now reside in ./drivers/net/
|
|
and *not* ./inet/net/ --- pg.)
|
|
|
|
Beware that if you put a '509 in EISA addressing mode
|
|
by mistake and save that in the EEPROM, you'll have
|
|
to use an EISA machine or the infamous Test Via to
|
|
get it back to normal, and it will conflict at IO
|
|
location 0 which may hang your ISA machine. It's not
|
|
my job to say whether this is a bug or feature, but I
|
|
have heard loud and clear that customers don't like
|
|
it and I don't think we'll do it that way again."
|
|
|
|
Unsupported:
|
|
|
|
3c501
|
|
Too brain-damaged to use. Available surplus from many
|
|
places. Avoid it like the plague. Again, do not
|
|
purchase this card, even as a joke. It's performance
|
|
is horrible, and it breaks in many ways.
|
|
|
|
(I have a standing offer: I'll pay $2 for each 3c501
|
|
shipped to me postpaid, but only if you include the
|
|
BNC 'T' connector and the jumpers. $2.50 if you just
|
|
send the 'T', jumpers, and address PROM and promise to
|
|
destroy the board. -djb)
|
|
|
|
Cameron L. Spitzer of 3Com said:
|
|
"I'm speaking only for myself here, of course, but I
|
|
believe 3Com advises against installing a 3C501 in a
|
|
new system, mostly for the same reasons Donald has
|
|
discussed. You probably won't be happy with the
|
|
3C501 in your Linux box. The data sheet is marked
|
|
"(obsolete)" on 3Com's Developers' Order Form, and
|
|
the board is not part of 3Com's program for sending
|
|
free Technical Reference Manuals to people who need
|
|
them. The decade-old things are nearly
|
|
indestructible, but that's about all they've got
|
|
going for them any more."
|
|
|
|
For those not yet convinced, the 3c501 can only do one
|
|
thing at a time -- while you are removing one packet
|
|
from the single-packet buffer it cannot receive
|
|
another packet, nor can it receive a packet while are
|
|
loading a transmit packet. This was fine for a
|
|
network between two 8088-based computers where
|
|
processing each packet and replying took 10's of
|
|
msecs, but modern networks send back-to-back
|
|
packets for almost every transaction.
|
|
|
|
Having read this far, you must be persistent, so you
|
|
get let in on a secret. As of pl13, some more of
|
|
the hardware problems were "compensated for".
|
|
|
|
Ie. in a fit of madness I wasted a whole day updating
|
|
my 3c501 driver and then trying to track down a few
|
|
more of the 3c501 glitches. It now works well enough
|
|
to NFS mount filesystems, but the receiver still
|
|
occasionally hangs. I'm mostly certain that this is
|
|
a hardware bug. When it hangs, the next set of
|
|
outgoing packets will reset the board, but that's
|
|
only useful if you have something occasionally
|
|
generating outgoing packets.
|
|
|
|
The driver is now in the std. kernel, but under the
|
|
following conditions: This is unsupported code. I
|
|
know my usual copyright says all the code is
|
|
unsupported, but this is _really_ unsupported. I
|
|
DON'T want to see bug reports, and I'll accept bug
|
|
fixes only if I'm in a good mood that day.
|
|
|
|
I don't want to see a fest of "Linux ethercards for
|
|
sale" postings. A bunch of people have bought dozens
|
|
of "dumpster special" 3c501s, and they hope to sell
|
|
them at rip-off prices. A 3c501 is barely worth the
|
|
shipping cost, and if I see people trying to sell
|
|
them here by claiming "supported by Linux" I _will_
|
|
flame them. They are _not_ supported by Linux.
|
|
|
|
I don't want to be flamed later for putting out bad
|
|
software. I don't know all all of the 3c501 bugs,
|
|
and I know this driver only handles a few that I've
|
|
been able to figure out. It has taken a long
|
|
intense effort just to get the driver working this
|
|
well.
|
|
|
|
That said, you will find it included in "config.in"
|
|
No special mods are needed to use it with pl15
|
|
or greater kernels. Jumper your card to 0x280.
|
|
|
|
AutoIRQ works, DMA isn't used, the autoprobe only
|
|
looks at 0x280, the debug level is set with the third
|
|
boot-time argument. You'll probably want to change
|
|
the default EL_DEBUG to '2'.
|
|
|
|
Once again, THE USE OF A 3c501 IS STRONGLY DISCOURAGED
|
|
and it is NOT SUPPORTED BY LINUX.
|
|
|
|
|
|
3c505
|
|
An Intel-based ethercard with no driver available
|
|
at present. (Not a very common card.)
|
|
|
|
3c507
|
|
This card uses one of the Intel chips, and the
|
|
development of the driver is closely related to
|
|
the development of the Intel Ether Express driver.
|
|
The driver has been included in the standard
|
|
release of pl15. You will have to un-comment
|
|
the 3c507 line in "config.in" -- in case you
|
|
didn't figure it out already, it is commented
|
|
out because it is still being tested.
|
|
|
|
Technical information is available in section 5.06,
|
|
and if you have experience in writing drivers, see
|
|
section 5.07 as well.
|
|
|
|
2.02 Western Digital / SMC
|
|
|
|
The ethernet part of Western Digital has been bought by SMC. The
|
|
SMC Elite and SMC Elite Plus are the same as late-model WD8003
|
|
and WD8013 cards. Note that the SMC Elite Ultra is *not* the
|
|
same as the plain SMC Elite / WD8013 card. (see below)
|
|
|
|
Supported:
|
|
|
|
WD8003, WD8013, SMC Elite, SMC Elite Plus
|
|
A shared memory design by Western Digital. The
|
|
8 bit 8003 is slightly less expensive, but only
|
|
worth the savings for light use. 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 Elite Plus (WD8013).
|
|
The shared memory makes the cards 10-20% faster,
|
|
especially with larger packets. More importantly
|
|
(to me at least) it avoids a few bugs in the
|
|
programmed-I/O mode of the 8390, allows safe
|
|
multi-threaded access to the packet buffer, and
|
|
doesn't have a programmed-I/O data register that
|
|
hangs your machine during warm-boot probes.
|
|
|
|
SMC Elite 16 ULTRA
|
|
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.
|
|
|
|
Some of the device probe checks in pl14 were too
|
|
too strict, causing some cards to not be detected
|
|
every time. This was fixed for pl14a, and hence is
|
|
fine for pl15. 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 pl14, and made possible by documentation
|
|
and ethercard loan from kamstra@ccmail.west.smc.com,
|
|
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!
|
|
|
|
I'm considering writing 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 right away.
|
|
Performance re-writes of working drivers are low
|
|
priority unless there is some particular incentive
|
|
or need.
|
|
|
|
2.03 NExxxx
|
|
|
|
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.
|
|
|
|
Supported:
|
|
|
|
NE1000, NE2000
|
|
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 clones. See the question and answer section
|
|
later in this document, and the section on clones.
|
|
I have written a NE2000 diagnostic program, but it
|
|
is still presently in alpha test. (ne2k)
|
|
|
|
NE1500, NE2100
|
|
The AT1500 driver, recently added to the list of
|
|
supported cards, also supports the NE1500, NE2100 and
|
|
clones. The driver shipped with pl12 kernel doesn't
|
|
detect non-AT1500 cards with autoprobe, but will work
|
|
fine if you specify the base address explicitly and
|
|
jumper for DMA channel 5. Read the Allied Telesis
|
|
section for more information on LANCE based cards.
|
|
|
|
2.04 Hewlett Packard
|
|
|
|
The 272** cards use programmed I/O, similar to the NE*000 boards,
|
|
but the data transfer port can be "turned off" when you aren't
|
|
accessing it, avoiding problems with autoprobing drivers.
|
|
|
|
Thanks to Glenn Talbott for cleaning up the confusion in this
|
|
section regarding the version numbers of the HP hardware, and
|
|
adding lots of new info.
|
|
|
|
Supported:
|
|
|
|
27245A
|
|
8 Bit 8390 based 10BaseT, not recommended for all the
|
|
8 bit reasons. It was re-designed a couple years
|
|
ago to be highly integrated which caused some
|
|
changes in initialization timing which only
|
|
affected testing programs, not LAN drivers. (The
|
|
new card is not 'ready' as soon after switching
|
|
into and out of loopback mode.)
|
|
|
|
27247B, 27252A
|
|
The 47B is a 16 Bit 8390 based 10BaseT w/AUI, and
|
|
the 52A is a 16 Bit 8390 based ThinLAN w/AUI.
|
|
These cards are high performers (3c509 speed) without
|
|
the interrupt latency problems (32K onboard RAM for TX
|
|
or RX packet buffering). They both offer LAN
|
|
connector autosense, data I/O in I/O space (simpler) or
|
|
memory mapped (faster), and soft configuration. 27247B
|
|
was rated Best for ISA Servers by PC Mag this year.
|
|
|
|
27247A
|
|
This is the older model that existed before the "B".
|
|
Two versions 27247-60001 or 27247-60002 have part
|
|
numbers marked on the card. Functionally the same to
|
|
the LAN driver, except bits in ROM to identify
|
|
boards differ. -60002 has a jumper to allow
|
|
operation in non-standard ISA busses (chipsets
|
|
that expect IOCHRDY early.)
|
|
|
|
HP J2405A
|
|
These are lower priced, and slightly faster than the
|
|
27247B/27252A, but are missing some features, such
|
|
as AUI, ThinLAN connectivity, and boot PROM socket.
|
|
This is a fairly generic LANCE design, but a minor
|
|
design decision makes it incompatible with a generic
|
|
"NE2100" driver. Special support for it (including
|
|
reading the DMA channel from the board) is in pl14
|
|
and up, thanks to information provided by HP's Glenn
|
|
Talbott, gt@hprnd.rose.hp.com. Note that the pre pl14
|
|
driver should not be used with this card.
|
|
|
|
More information on LANCE based cards can be found in
|
|
section 5.08.
|
|
|
|
2.05 D-Link
|
|
|
|
Supported:
|
|
|
|
DE-600
|
|
Laptop users and other folk who might want a quick
|
|
way to put their computer onto the ethernet may want
|
|
to use this. The driver was included with the default
|
|
kernel source tree as of pl12 and possibly earlier.
|
|
Bjorn Ekwall <bj0rn@blox.se> wrote the original.
|
|
Expect about 80kb/s transfer speed from this via the
|
|
parallel port. You should read the README.DLINK
|
|
file in the kernel source tree. The latest release
|
|
of this driver is v0.32, and it is included in the
|
|
standard kernel of pl15
|
|
|
|
DE-650
|
|
Some people have been using this PCMCIA card for
|
|
some time now with their notebooks. Note however,
|
|
that using a PCMCIA card with Linux is not trivial.
|
|
See the section on networking with a notebook for
|
|
more information on PCMCIA cards. This driver is
|
|
*not* part of the standard kernel.
|
|
|
|
DE-100, DE-200, DE-220-T
|
|
The manual says that it is 100% compatible with the
|
|
NE2000. This is not true. You should call them and
|
|
tell them you are using their card with Linux, and they
|
|
should correct their documentation. Some pre-0.99pl12
|
|
driver versions may have trouble recognizing the DE2**
|
|
series as 16 bit cards, and these cards are the most
|
|
widely reported as having the spurious transfer address
|
|
mismatch errors. Note that there are cards from
|
|
Digital (DEC) that are also named DE100 and DE200,
|
|
but the similarity stops there.
|
|
|
|
Unsupported:
|
|
|
|
DE-620
|
|
Same as the DE-600, only with two output formats.
|
|
(BNC and RJ-45, I would assume... ????)
|
|
Bjorn writes: "I have still no information on the
|
|
DE-620 that I can include in this release. (Maybe
|
|
someone well connected to D-Link sees this,
|
|
hint, hint, hint...)
|
|
|
|
2.06 Cabletron
|
|
|
|
Yes, another one of these companies that won't release its
|
|
programming information. They waited for months before actually
|
|
confirming that all their information was proprietary, deliberately
|
|
wasting my time. Avoid their cards like the plague if you can.
|
|
Also note that some people have phoned Cabletron, and have been
|
|
told things like "a dbecker@super.org is working on a driver
|
|
for linux" -- making it sound like I work for them. This is
|
|
NOT the case. Anyway, if I were working for them, or even if
|
|
I had signed a ND agreement, I wouldn't be able to tell
|
|
everyone what a sleazy design the E2100 is. (See below.)
|
|
|
|
If you feel like asking them why they don't want to release their
|
|
info so that people can use their cards, write to support@ctron.com
|
|
Tell them that you are using Linux, and are disappointed that they
|
|
don't support open systems. (See section 9.01)
|
|
|
|
Supported: (...well, not *really* supported)
|
|
|
|
E10**, E10**-x, E20**, E20**-x
|
|
These are NEx000 almost-clones that are reported to
|
|
work with the standard NEx000 drivers, thanks to a
|
|
ctron-specific check during the probe. If there are
|
|
any problems, they are unlikely to be fixed, as the
|
|
programming information is unavailable.
|
|
|
|
|
|
E21**
|
|
Again, there is not much one can do when the
|
|
programming information is proprietary.
|
|
The E2100 is a poor design. Whenever it maps its
|
|
shared memory in during a packet transfer, it
|
|
maps it into the *whole 128K region*! That means you
|
|
*can't* safely use another interrupt-driven shared
|
|
memory device in that region, including another E2100.
|
|
It will work _most_ of the time, but every once in
|
|
a while it will bite you. (Yes, this problem can
|
|
be avoided by turning off interrupts while
|
|
transferring packets, but that will almost certainly
|
|
lose clock ticks.
|
|
|
|
Also, don't confuse the E2100 for a NE2100 clone.
|
|
The E2100 is a shared memory NatSemi DP8390 design,
|
|
roughly similar to a brain-damaged WD8013, whereas
|
|
the NE2100 (and NE1500) use a bus-mastering AMD
|
|
LANCE design.
|
|
|
|
There is an alpha test driver available (even though
|
|
I shouldn't have bothered) in the normal place
|
|
(see the FAQ section) -- e2100.c -- let me know if
|
|
you use it, and how it works. Don't forget to
|
|
un-comment the line in config.in.
|
|
|
|
2.07 Allied Telesis
|
|
|
|
Allied Telesis is the worlds largest maker of separate
|
|
transceivers thanks to their low prices, and they now have a
|
|
series of low-cost ethercards using the 79C960 version of the AMD
|
|
LANCE. These are bus-master cards, and thus probably the fastest
|
|
ISA bus ethercards available (although the 3c509 has lower latency
|
|
thanks to predictive interrupts).
|
|
|
|
Supported:
|
|
|
|
AT1500
|
|
The driver for the AT1500 series is new in the
|
|
0.99pl12 kernel, but it won't work "out-of-the-box"
|
|
with >16M machines. (NB This isn't a fundamental
|
|
limitation, so stop pointing and laughing at the ISA
|
|
bus. The driver just needs a hook to allocate
|
|
low-memory buffers for the bus-master DMA, and should
|
|
be just as fast on >16M systems. It can be easily
|
|
fixed by initializing the LANCE driver with the
|
|
character devices, but this fix depends on the
|
|
resolution of the networking code uncertainty.)
|
|
|
|
For the ISA bus master mode all structures used
|
|
directly by the LANCE, the initialization block,
|
|
Rx and Tx rings, and data buffers, must be accessible
|
|
from the ISA bus, i.e. in the lower 16M of real memory.
|
|
This is a problem for current Linux kernels on >16M
|
|
machines. The network devices are initialized after
|
|
memory initialization, and the kernel doles out memory
|
|
from the top of memory downward. The current solution
|
|
is to have a special network initialization routine
|
|
that's called before memory initialization; this will
|
|
eventually be generalized for all network devices.
|
|
Low-memory "bounce-buffers" are used when needed.
|
|
|
|
This driver should also work with NE1500 and NE2100
|
|
clones.
|
|
|
|
Future driver versions may figure out a way to
|
|
autoDMA. Although there is no autoDMA (until I verify
|
|
that autoDMA is safe and reliable), some versions
|
|
(pl13) allow passing the DMA channel at boot-time via
|
|
LILO. (Boot-time parameters can be made permanent in
|
|
LILO v13+, read the docs.) The DMA channel otherwise
|
|
defaults to DMA5.
|
|
|
|
In pl14, there was a buglet that would hang some
|
|
machines with AT1500 like cards. Either get pl15
|
|
or newer, or go into ./init/main.c and move the
|
|
sti(); and claibrate_delay(); (near line 366) in
|
|
*front of* the #ifdef CONFIG_INET, instead of
|
|
after it.
|
|
|
|
Please report the exact chip used by your ethercard,
|
|
and any success or failure you have. This driver is
|
|
still young, and I've gotten few reports.
|
|
|
|
More information on AMD LANCE based Ethernet cards
|
|
can be found in section 5.08.
|
|
|
|
AT1700
|
|
The Allied Telesis AT1700 series ethercards are based
|
|
on the Fujitsu MB86965. This chip uses a programmed
|
|
I/O interface, and a pair of fixed-size transmit
|
|
buffers. This allows small groups of packets to sent
|
|
be sent back-to-back, with a short pause while
|
|
switching buffers.
|
|
|
|
A unique feature is the ability to drive 150ohm STP
|
|
(Shielded Twisted Pair) cable commonly installed for
|
|
Token Ring, in addition to 10baseT 100ohm UTP
|
|
(unshielded twisted pair).
|
|
|
|
A mis-feature to watch out for is that the current
|
|
production version silently wires to DMA channel 5,
|
|
rendering it useless. No device driver will be
|
|
written using DMA if installing a second card into
|
|
the machine breaks both, and the only way to disable
|
|
the DMA is with a knife.
|
|
|
|
The at1700 driver is included in the standard pl15
|
|
kernel source tree.
|
|
|
|
2.08 Arcnet
|
|
|
|
There is no Arcnet driver for Linux. Feel free to write a driver. With
|
|
the very low cost and better performance of ethernet, I expect that
|
|
most places will be giving away their Arcnet hardware for free,
|
|
resulting in a lot of home systems with Arcnet.
|
|
|
|
An advantage of Arcnet is that all of the cards have identical
|
|
interfaces, so once a driver is available it will work for everyone.
|
|
|
|
2.09 Digital / DEC
|
|
|
|
Supported: DE200, DE210, DE202, DE100, DEPCA rev E
|
|
|
|
As of linux v1.0, there is a driver included as standard
|
|
for these cards. It was written by David C. Davies.
|
|
There is documentation included in the source file
|
|
"depca.c", which includes info on how to use more than
|
|
one of these cards in a machine.
|
|
|
|
If you have / want to use the pl15 kernel or older,
|
|
then you will have to use Peter Bauer's driver.
|
|
It can be found as a separate patch called depca-0.8.tar.gz.
|
|
You will have to un-comment the DEPCA line in "config.in"
|
|
after installing the patch. You can find the patch on
|
|
ftp.funet.fi, /pub/OS/Linux/BETA/depca/depca-0.8.tar.gz
|
|
This version resets the card upon close so that you can
|
|
use it with broken DOS drivers after a warm boot.
|
|
|
|
|
|
Unsupported: Digital Etherlink III
|
|
|
|
Peter Bauer said that "the new etherlink III seems to
|
|
be a break: No official docu from DEC as far as today,
|
|
other (incompatible??) hardware used, and (no joke) (at least
|
|
for the first delivered cards) also a sharp knife necessary
|
|
to get the card working (needs cut of some irq lines ...)
|
|
As far as I know, lots of DEC Employees use Linux (at least
|
|
for hobby purposes) and the depca-driver, because its a
|
|
de-facto standard in DEC, so I encourage any DEC-employee
|
|
reading this to check wether my writing is true, and to
|
|
support sources of information about the etherworks-III."
|
|
|
|
2.10 Intel Ethernet Cards
|
|
|
|
Supported: Ether Express
|
|
|
|
This card uses the intel i82586. (Surprise, huh?)
|
|
The driver is in the standard release of pl15.
|
|
However, you will have to uncomment the line in
|
|
"config.in" to use it. -- yes, this line is
|
|
commented out for a reason. The driver is still
|
|
in the testing phases, as of v1.0 as well.
|
|
|
|
There is some technical information available on
|
|
the i82586 in section 5.06, and also in the
|
|
source code for the driver "eexpress.c". Don't
|
|
be afraid to read it. ;-)
|
|
|
|
The rason is that the driver works well with slow machines,
|
|
but the i82586 occasionally hangs from the packet buffer
|
|
contention that a fast machine can cause. I'll have
|
|
to find a work-around before releasing the driver.
|
|
One reported hack fix is to change all of the outw()
|
|
calls to outw_p().
|
|
|
|
|
|
If you do try the driver please post or send a report.
|
|
Include the kind of machine you are trying it with,
|
|
and how heavily loaded your network is.
|
|
|
|
|
|
2.11 PureData
|
|
|
|
Supported: PDUC8028, PDI8023
|
|
|
|
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.
|
|
|
|
2.12 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. Read section
|
|
9.01 if you are bored.
|
|
|
|
And if you just want to verify that this is the case, you can
|
|
reach Xircom at 1-800-874-7875 or +1-818-878-7600.
|
|
|
|
2.13 Zenith
|
|
|
|
The built-in Z-Note network adaptor is based on the Intel
|
|
i82593 using two DMA channels. There might be a driver for it
|
|
in mid 1994. See section 5.06 for more information.
|
|
Also note that the Z-Note is compatible with the IBM ThinkPad 300.
|
|
|
|
2.14 Racal-Interlan
|
|
|
|
Note: I have been told that the following two drivers are
|
|
for patchlevel 11, and hence are a bit dated. The original
|
|
author is Michael Hipp, and can be reached at the following addr:
|
|
zxmhp01@student.uni-tuebingen.de
|
|
|
|
NI52**
|
|
|
|
There is an alpha driver for the NI5210 floating about.
|
|
(last seen on tsx-11.mit.edu /pub/linux/ALPHA/ni/ni52.tar.gz)
|
|
This card also uses one of the Intel chips. See section
|
|
5.06 for more information.
|
|
|
|
NI65**
|
|
|
|
There is also a driver for the LANCE based NI6510, and it
|
|
can be found in the same place as the NI5210 driver above.
|
|
I am not sure how much work it would be to hack the current
|
|
LANCE driver in the kernel to support this card. If anyone
|
|
has done so, let me know.
|
|
|
|
2.15 AMD LANCE (79C960)
|
|
|
|
There really is no AMD ethernet card. You are probably reading this
|
|
because the only markings you could find on your card said AMD
|
|
and the above number. The above number refers to a chip from AMD
|
|
that is the heart of many ethernet cards. See the section on the
|
|
Allied Telesis AT1500, the NE1500/2100 and the information in
|
|
section 5.08. Chances are that the existing LANCE driver will work
|
|
with all AMD LANCE based cards. (...except perhaps the above
|
|
mentioned NI6510 ???)
|
|
|
|
2.16 AT-Lan-Tec / RealTek Pocket adaptor
|
|
|
|
This is a generic, low-cost OEM pocket adaptor being sold by
|
|
AT-Lan-Tec, and (likely) a number of other suppliers. A
|
|
driver for it is included in the standard pl15 kernel.
|
|
Note that there is substantial information contained in the
|
|
driver source file "atp.c" which presently lives in ./drivers/net/
|
|
BTW, the adaptor (AEP-100L) has both 10baseT and BNC connections!
|
|
You can reach AT-Lan-Tec at 1-301-948-7070. Ask for the model
|
|
that works with Linux, or ask for "Vincent Bono" in tech support.
|
|
In the Netherlands a compatible adaptor is sold under the name SHI-TEC
|
|
PE-NET/CT, and sells for about $125. The vendor was Megasellers.
|
|
They state that they do not sell to private persons, but I just
|
|
gave them the name of my home institute. No questions asked.
|
|
They are: Megasellers, Vianen, The Netherlands. They always
|
|
advertise in Dutch computer magazines. In Germany, a similar
|
|
adaptor comes as a no-brand-name product. Prolan 890b, no
|
|
brand on the casing, only a roman II. Resellers can get a price
|
|
of about $130, including a small wall transformer for the power.
|
|
|
|
Physical Description
|
|
|
|
The adaptor is "normal size" for the product class, about 57mm wide,
|
|
22mm high tapering to 15mm high at the DB25 connector, and 105mm long
|
|
(120mm including the BNC socket). It's switchable between the RJ45
|
|
and BNC jacks with a small slide switch positioned between the two:
|
|
a very intuitive design.
|
|
|
|
It's powered by a lightweight 5V "wall brick" adaptor that terminates
|
|
in a standard 5.0mm power connector. I measured an unconnected
|
|
quiescent power draw of 102ma for BNC and 84ma for 10baseT. I hooked
|
|
the pocket adaptor up to my home thinnet and started FTPing a large
|
|
file. The power measurements were:
|
|
|
|
idle, connected 99ma @ 5.1V
|
|
active, connected 107ma @ 5.1V
|
|
|
|
This was measured using a Fluke 8026B true-RMS multimeter, so I'm
|
|
pretty confident the numbers are good. This power draw is low enough
|
|
that you could buy or build a cable to take the 5V directly from the
|
|
keyboard/mouse port available on many laptops. (Bonus points here
|
|
for using a standardized power connector instead of proprietary one.)
|
|
|
|
2.17 Ansel
|
|
|
|
Supported: AC3200 EISA
|
|
|
|
This driver is not included in the pl15 kernel. To
|
|
*alpha* test it, get the files ac3200.[c,h] from
|
|
where you usually get alpha drivers (see the FAQ in
|
|
this document if you dont know) and uncomment the
|
|
line in config.in for the ac3200. If you use it,
|
|
please let me know how things work out.
|
|
|
|
2.18 DFI
|
|
|
|
Supported: DFINET-300 (NE1000) and DFINET-400 (NE2000)
|
|
|
|
These cards are now detected (as of pl15) thanks to
|
|
Eberhard Moenkeberg <emoenke@gwdg.de> who noted that
|
|
they use "DFI" in the first 3 bytes of the prom, instead
|
|
of using 0x57 in bytes 14 and 15, which is what all the
|
|
NE1000 and NE2000 cards use.
|
|
|
|
3. 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 question and answer section of this document.
|
|
|
|
Also note that if your card isn't mentioned here, that really
|
|
means nothing. Chances are that even if it is only a half decent
|
|
clone of the original, then it will still work.
|
|
|
|
3.1 WD80x3 clones
|
|
|
|
The following clones are reported to work with the standard
|
|
WD80x3 driver:
|
|
|
|
AT-LAN-TEC 8013
|
|
PureData (not a 8013 clone, but the 8013 driver has special code)
|
|
LANNET LEC-45
|
|
PE-8013 (WD-8013 Compatible)
|
|
|
|
3.2 NE2000 clones
|
|
|
|
The following clones are reported to work with the standard
|
|
NE2000 driver:
|
|
|
|
Accton NE2000 (might not get detected at boot, see section 6)
|
|
Alta Combo NE2000 clone
|
|
Aritsoft LANtastic AE-2 (OK, but has flawed error-reporting registers)
|
|
Asante Etherpak 2001/2003
|
|
AT-LAN-TEC NE2000 clone (uses Winbond chip that traps SCSI drivers)
|
|
Cabletron products: E10**, E10**-x, E20**, E20**-x
|
|
Cnet UTP 10baseT (NE 2000 emulation)
|
|
D-Link Ethernet II (bad clones, but the driver checks for them)
|
|
4-Dimension FD0490 EtherBoard16
|
|
LTC E-NET/16 P/N: 8300-200-002 (lipka@lip.hanse.de)
|
|
Network Solutions HE-203
|
|
SIIG Inc E-Lan/200 (NE 2000 comp.)
|
|
SVEC 4 Dimension Ethernet
|
|
|
|
4. Cables, coax, twisted pairs etc.
|
|
|
|
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.
|
|
|
|
4.01 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.09/ft. and
|
|
stranded RG58AU is $0.15/ft. 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!
|
|
|
|
|
|
4.02 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,
|
|
Falleron 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. IMO, you 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.)
|
|
|
|
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).
|
|
|
|
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."
|
|
|
|
4.03 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.
|
|
|
|
|
|
-- end of part 1 of 2 --
|
|
From: Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
Newsgroups: comp.os.linux.announce,comp.os.linux.admin,comp.answers,news.answers
|
|
Subject: Linux Ethernet HOWTO (Part 2/2)
|
|
Keywords: Linux, Ethernet, TCP/IP, NET-2, network
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-Name: linux/howto/ethernet/part2
|
|
Last-Modified: 16 Mar 1994
|
|
|
|
[This is part 2/2 of the Ethernet-HOWTO.]
|
|
|
|
5 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.
|
|
|
|
5.01 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. As of 0.99pl12, doing a "make config"
|
|
will ask what cards are to be supported. The file names below are
|
|
in /usr/src/linux/drivers/net/
|
|
----------------------------------------------------------------
|
|
wd.c: 0x300, 0x280, 0x380, 0x240
|
|
3c501.c 0x280
|
|
3c503.c: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
|
|
3c507.c: 0x300, 0x320, 0x340, 0x280
|
|
3c509.c: <Special "ID Port" probe>
|
|
at1700.c: 0x300, 0x280, 0x380, 0x320, 0x340, 0x260, 0x2a0, 0x240
|
|
atp.c: 0x378, 0x278, 0x3bc
|
|
depca.c 0x300, 0x200
|
|
d_link.c: 0x378
|
|
ne.c: 0x300, 0x280, 0x320, 0x340, 0x360
|
|
hp.c: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
|
|
lance.c: 0x300, 0x320, 0x340, 0x360
|
|
smc-ultra.c: 0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380
|
|
eexpress.c: 0x300, 0x270, 0x320, 0x340
|
|
3c509.c: <Special "ID Port" probe>
|
|
----------------------------------------------------------------
|
|
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.
|
|
|
|
To avoid these lurking ethercard, 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
|
|
|
|
In other news, I've written the code for the I/O port registrar.
|
|
Peter MacDonald and I have been intensely discussing this, and I think
|
|
our current scheme has the necessary functionality with minimal kernel
|
|
size impact. (The implementation involved rewriting the bitmap ops in
|
|
kernel/ioport.c:ioperm() so that most code could be shared.)
|
|
|
|
Here is the current "blurb". As usual comments are welcome. Please
|
|
keep them substantial and constructive (we've already talked about
|
|
changing the name from "reserve=" to "noprobe=").
|
|
|
|
==================
|
|
|
|
Boot-Time Parameters: "reserve="
|
|
|
|
In some machines it may be necessary to prevent device drivers from
|
|
checking for devices (auto-probing) in a specific region. This may be
|
|
because of poorly designed hardware that causes the boot to "freeze"
|
|
(such as some ethercards), hardware that is mistakenly identified,
|
|
hardware whose state is changed by an earlier probe, or merely
|
|
hardware you don't want the kernel to initialize.
|
|
|
|
The "reserve" boot-time argument addresses this problem by specifying
|
|
an I/O port region that shouldn't be probed. That region is reserved
|
|
in the kernel's port registration table as if a device has already
|
|
been found in that region. Note that this mechanism shouldn't be
|
|
necessary on most machine, only when there is a problem or special
|
|
case.
|
|
|
|
The boot-line syntax is
|
|
|
|
lilo-prompt: linux-image reserve=[<port>,<size>,<port>,<size>...]
|
|
|
|
As usual with boot-time specifiers there is an 11 parameter limit, thus
|
|
you can only specify 5 reserved regions per "reserve" keyword.
|
|
Multiple "reserve" specifiers will work if you have an usually
|
|
complicated request.
|
|
|
|
If you specify a "reserve" region to protect a specific device, you
|
|
must generally specify an explicit probe for that device. Most
|
|
drivers ignore the port registration table if they are given an
|
|
explicit address.
|
|
|
|
5.02 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 require-
|
|
ments ;-) 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.
|
|
|
|
5.03 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 an
|
|
socket ioctl() usually called by 'config' or '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).
|
|
|
|
(Note: As of NET-2, the relevant program is '/etc/ifconfig' - and
|
|
the device *can* be turned off or on via passing 'up' or 'down'
|
|
to 'ifconfig' from the command line with the device name.)
|
|
|
|
=====================================================
|
|
|
|
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).
|
|
[[Note: pre0.99.4 kernels didn't use this interface for all packets.]]
|
|
|
|
=====================================================
|
|
|
|
...
|
|
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 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.
|
|
|
|
=====================================================
|
|
|
|
5.04 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 pl14 kernels and newer. He says:
|
|
|
|
"Any driver intended for pl14 should use the new alloc_skb() and
|
|
kfree_skbmem() functions rather than using kmalloc() to obtain an
|
|
sk_buff. The new pl14 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 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."
|
|
|
|
|
|
5.05 Programmed I/O vs. shared mem. vs. slave/master 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:
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Slave (normal) DMA
|
|
==================
|
|
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.
|
|
|
|
Master (bus-master) DMA
|
|
=======================
|
|
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.
|
|
|
|
5.06 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."
|
|
|
|
5.07 Technical information from 3Com
|
|
|
|
From: Cameron Spitzer 764-6339 <camerons@nad.3com.com>
|
|
Subject: getting 3Com Adapter manuals
|
|
Date: Mon, 27 Sep 1993 21:17:07 +0200
|
|
|
|
Since this is becoming a FAQ, I'm going to tread the thin
|
|
ice of No Commercial Use and answer it here.
|
|
|
|
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
|
|
|
|
5.08 Notes on AMD PCnet-ISA / LANCE Based cards (79C960)
|
|
|
|
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.
|
|
|
|
The PCnet-ISA is faster than the original LANCE design and
|
|
makes better use of the available bus bandwidth. Additionally, some
|
|
LANCE bugs were corrected and many enhancements were made."
|
|
|
|
There is also some info regarding the LANCE chip in the file
|
|
lance.c which is included in the standard kernel.
|
|
|
|
5.09 Multicast and Promiscuous mode
|
|
|
|
One of the things I've been working on recently is the
|
|
major remaining item on the ethercard feature list:
|
|
implementing multicast and promiscuous mode hooks.
|
|
|
|
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 next section for more information on BPF.
|
|
|
|
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 (pl14 and up.)
|
|
|
|
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.
|
|
|
|
Alan Cox adds that "...in pl14, user programs can access promiscuous
|
|
mode but not multicast mode, even though the drivers support both.
|
|
The ifconfig program allows you to mark an interface 'promisc'."
|
|
|
|
5.10 The Berkeley Packet Filter (BPF)
|
|
|
|
I'm not bitterly opposed to it, but I'm coming to the
|
|
conclusion 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.
|
|
|
|
5.11 Unresolved questions / concerns
|
|
|
|
There may be some benefit from processing packet data as it is
|
|
transferred to and from the ethercard, especially with very fast
|
|
processors transferring data to a slow ethercard. As I see it this
|
|
question has multiple parts:
|
|
1) Is there any useful processing power available, perhaps
|
|
during the ISA bus recovery period, or while the 8390
|
|
remote DMA is preparing for another transfer??
|
|
2) Is there any useful but simple work that can be done
|
|
between/during each word of the copy, such as calculating
|
|
a CRC, or discarding obviously unwanted packets??
|
|
3) would the complexity of an interface to do this make future
|
|
ethercard drivers impossible??
|
|
|
|
There should be a better structure than Space.c - Drivers should be
|
|
able to autoprobe for all installed ethercards rather than just
|
|
quitting after finding the first. I've written code to do this,
|
|
but the constant promise (threat?) of DDI has prevented me from
|
|
making it standard.
|
|
|
|
A related topic is the problem of driver probes corrupting
|
|
unrelated hardware. Even worse is a probe into a dataport that
|
|
isn't set up to transfer data, which will freeze the machine. The
|
|
common suggestion is a boot-time device registry that records
|
|
already-used I/O ports and shared memory. This has been implemented
|
|
as of pl13, see section 5.01.
|
|
|
|
6 Possible problems, and troubleshooting.
|
|
|
|
This section tries to answer any unresolved questions, and not so
|
|
common solutions to common problems. They are sorted on a "per
|
|
manufacturer basis". You should have also read the relevant info.
|
|
from section 1 about your specific card. Section 8 contains more
|
|
general FAQ's.
|
|
|
|
6.01 Problems with NE2000 (and clones)
|
|
|
|
"DMA address mismatch"
|
|
======================
|
|
|
|
Is the chip a real NatSemi 8390? (DP8390, DP83901, DP83902 or DP83905)?
|
|
If not, some clone chips don't correctly implement the transfer
|
|
verification register. MS-DOS drivers never do error checking,
|
|
so it doesn't matter to them.
|
|
|
|
Are most of the messages off by a factor of 2?
|
|
If so: Are you using the NE2000 in a 16 bit slot?
|
|
Is it jumpered to use only 8 bit transfers?
|
|
|
|
The Linux driver expects a NE2000 to be a 16 bit slot. A NE1000 can
|
|
be in either size slot. This problem can also occur with some clones,
|
|
notably D-Link 16 bit cards, that don't have the correct ID bytes
|
|
in the station address PROM. [[ This should be fixed in pl12.]]
|
|
|
|
Are you running the bus faster than 8Mhz?
|
|
If you can change the speed (faster or slower), see if that
|
|
makes a difference. Most NE2000 clones will run at 16Mhz, but
|
|
some may not. Changing speed can also mask a noisy bus.
|
|
|
|
What other devices are on the bus?
|
|
If moving the devices around changes the reliability, then you
|
|
have a bus noise problem -- just what that error message was
|
|
designed to detect. Congratulations, you've probably found the
|
|
source of other problems as well.
|
|
|
|
Machine Hangs during Boot.
|
|
==========================
|
|
|
|
Problem: The machine hangs during boot right after the "8390..." or
|
|
"WD...." message. Removing the NE2000 fixes the problem.
|
|
|
|
Solution: Change your NE2000 base address to 0x360 (or 0x340 for
|
|
pl12 or later kernels.) Alternatively, you can use the new
|
|
device registrar implemented in pl13 (see section 5.1)
|
|
|
|
Reason: Your NE2000 clone isn't a good enough clone. An active
|
|
NE2000 is a bottomless pit that will trap any driver
|
|
autoprobing in its space. The other ethercard drivers take
|
|
great pain to reset the NE2000 so that it's safe, but some
|
|
clones cannot be reset. Clone chips to watch out for:
|
|
Winbond 83C901. Changing the NE2000 to a less-popular
|
|
address will move it out of the way of other autoprobes,
|
|
allowing your machine to boot.
|
|
|
|
Problem: The machine hangs during the SCSI probe at boot.
|
|
|
|
Solution: It's the same problem as above, change the
|
|
ethercard's address, or use the device registrar.
|
|
|
|
Problem: The machine hangs during the soundcard probe at boot.
|
|
|
|
Solution: No, that's really during the silent SCSI probe, and it's
|
|
the same problem as above.
|
|
|
|
"eth0: DMAing conflict in ne_block_input"
|
|
=========================================
|
|
|
|
This bug came from timer-based packet retransmissions. If you got a
|
|
timer tick _during_ a ethercard RX interrupt, and timer tick tried to
|
|
retransmit a timed-out packet, you could get a conflict. Because of
|
|
the design of the NE2000 you would have the machine hang (exactly the
|
|
same the NE2000-clone boot hangs).
|
|
|
|
Early versions of the driver disabled interrupts for a long time,
|
|
and didn't have this problem. Later versions are fixed. (ie. kernels
|
|
after 0.99p9 should be OK.)
|
|
|
|
NE2000 not detected at boot.
|
|
============================
|
|
|
|
A few people have reported a problem with detecting the Accton NE2000.
|
|
This problem occurs only at boot-time, and the card is later detected
|
|
at run-time by the identical code my (alpha-test) ne2k diagnostic
|
|
program. Accton has been very responsive, but I still haven't tracked
|
|
down what is going on. I've been unable to reproduce this problem
|
|
with the Accton cards we purchased. If you are having this problem,
|
|
please send me an immediate bug report. For that matter, if you have
|
|
an Accton card send me a success report, including the type of the
|
|
motherboard. I'm especially interested in finding out if this problem
|
|
moves with the particular ethercard, or stays with the motherboard.
|
|
|
|
Here are some things to try, as they have fixed it for some people:
|
|
1) Change the bus speed, or just move the card to a different slot (!).
|
|
2) Change the "I/O recovery time" parameter in the BIOS
|
|
chipset configuration.
|
|
3) Make the following code change suggested by David Cutler,
|
|
<dave@dmitri.ucdavis.edu> to ne.c around line 150:
|
|
|
|
for(i = 0; i < 32 /*sizeof(SA_prom)*/; i+=2) {
|
|
- SA_prom[i] = inb_p(ioaddr + NE_DATAPORT);
|
|
- SA_prom[i+1] = inb_p(ioaddr + NE_DATAPORT);
|
|
+ SA_prom[i] = inb(ioaddr + NE_DATAPORT);
|
|
+ SA_prom[i+1] = inb(ioaddr + NE_DATAPORT);
|
|
if (SA_prom[i] != SA_prom[i+1])
|
|
wordlength = 1;
|
|
}
|
|
|
|
Yes, this removes the delay between board accesses, something that
|
|
would normally increase the likelihood of data corruption rather
|
|
than decreasing it. Note that this change is already incorporated
|
|
into pl15. If you have an older kernel, you may have to do it
|
|
yourself.
|
|
|
|
6.02 Problems with WD80*3 cards
|
|
|
|
Detected Non-existent Ethercard
|
|
===============================
|
|
|
|
Problem: A WD80*3 is falsely detected. Removing the sound or
|
|
MIDI card eliminates the "detected" message.
|
|
|
|
Solution: Update your ethercard driver: new versions include an
|
|
additional sanity check.
|
|
|
|
Reason: Some MIDI ports happen to produce the same checksum as a
|
|
WD ethercard.
|
|
|
|
Error messages from the 80*3
|
|
============================
|
|
|
|
Problem: You get messages such as the following with your 80*3:
|
|
eth0: bogus packet size, status = ........
|
|
kmalloc called with impossibly large argument (65400)
|
|
eth0: Couldn't allocate sk_buff of size 65400
|
|
eth0: receiver overrun
|
|
|
|
Reason: There is a shared memory problem.
|
|
|
|
Solution: If the problem is sporadic, you have hardware problems.
|
|
Typical problems that are easy to fix are board conflicts,
|
|
having cache or "shadow ROM" enabled for that region, or
|
|
running your bus faster than 8Mhz. There are also a
|
|
surprising number of memory failures on ethernet cards,
|
|
so run a diagnostic program if you have one for your
|
|
ethercard.
|
|
|
|
If the problem is continual, and you have have to reboot
|
|
to fix the problem, record the boot-time probe message
|
|
and mail it to becker@super.org - Take particular note of
|
|
the shared memory location.
|
|
|
|
Will not detect my 80x3
|
|
=======================
|
|
|
|
Reason: The Mitsumi CD-ROM (mcd) driver probe at 0x300 will
|
|
succeed if just about *anything* is that I/O location.
|
|
This is bad news and needs to be a bit more robust. (pl15)
|
|
Once another driver registers that it "owns" an I/O
|
|
location, other drivers (incl. the wd80x3) are "locked
|
|
out" and can not probe that addr for a card.
|
|
|
|
Solution: Recompile a new kernel without any excess drivers that
|
|
you aren't using, including the above mcd driver.
|
|
Or try moving your ethercard to a new I/O addr. Valid
|
|
I/O addr. for all the cards are listed in section 5.1
|
|
You can also point the mcd driver off in another direction
|
|
by a boot-time parameter (via LILO) such as:
|
|
"mcd=0x200,12"
|
|
|
|
6.03 Problems with 3Com cards
|
|
|
|
Choosing the Interrupt of the 3c503
|
|
===================================
|
|
|
|
Problem: The 3c503 picks IRQ n at boot, but this is needed for some
|
|
other device which needs IRQ n. (eg. CD ROM driver, etc.)
|
|
Can this be fixed without compiling this into the kernel?
|
|
|
|
Solution: The 3c503 driver probes for a free IRQ line in the order
|
|
{5, 9/2, 3, 4}, and it should pick a line which isn't being
|
|
used. The pre-pl12 (SLS 1.02) driver picked the IRQ line
|
|
at boot-time, and the current driver (pl12) chooses when
|
|
the card is open()/'ifconfig'ed. Note the "bug" noted in
|
|
the 3c503 section in 1.01
|
|
|
|
Alternately, you can fix the IRQ at boot by passing
|
|
parameters via LILO. The following selects IRQ9, base
|
|
location 0x300, <ignored value>, and if_port #1 (the
|
|
external transceiver).
|
|
lilo: linux ether=9,0x300,0,1,eth0
|
|
|
|
The following selects IRQ3, probes for the base location,
|
|
<ignored value>, and the default if_port #0 (the internal
|
|
transceiver)
|
|
lilo: linux ether=3,0,0,0,eth0
|
|
|
|
"3c503: Configured interrupt number XX is out of range."
|
|
========================================================
|
|
|
|
Problem: Whoever built your kernel fixed the ethercard IRQ at XX.
|
|
|
|
Reason: The above is truly evil, and worse than that, it is
|
|
not necessary. The 3c503 will autoIRQ when it gets
|
|
"ifconfig"ed, and pick one of IRQ{5, 2/9, 3, 4}.
|
|
|
|
Solution: Use lilo to set the IRQ, or rebuild the kernel, enabling
|
|
autoIRQ by not specifying the IRQ line.
|
|
|
|
Choosing the output of the 3c503
|
|
================================
|
|
|
|
Problem: The supplied 3c503 drivers don't use the AUI (thicknet) port.
|
|
How does one choose it over the default thinnet port?
|
|
|
|
Solution: The 3c503 AUI port can be selected at boot-time with 0.99pl12
|
|
and later. The selection is overloaded onto the low bit of
|
|
the currently-unused dev->rmem_start variable, so a boot-time
|
|
parameter of:
|
|
lilo: linux ether=0,0,0,1,eth0
|
|
should work. A boot line to force IRQ 5, port base 0x300,
|
|
and use an external transceiver is:
|
|
lilo: linux ether=5,0x300,0,1,eth0
|
|
|
|
7 Networking with a laptop 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 or 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.
|
|
|
|
7.01 Option 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.
|
|
|
|
7.02 Option 2 -- Built in NE2000 compatible or PCMCIA Ethercard.
|
|
|
|
The second solution severely limits your laptop choices and is fairly
|
|
expensive. Be sure to read the specifications carefully, you may find
|
|
that you will have to buy an additional non-standard transceiver to
|
|
actually put the machine on a network.
|
|
|
|
As this area of Linux development is fairly young, I'd suggest
|
|
that you join the LAPTOPS mailing channel. See section 0.02
|
|
which describes how to join a mailing list channel. Try and
|
|
determine exactly what hardware you have (ie. card manufacturer,
|
|
PCMCIA chip controller manufacturer) and then ask on the LAPTOPS
|
|
channel. Regardless, don't expect things to be all that simple.
|
|
Expect to have to fiddle around a bit, and patch kernels, etc.
|
|
Maybe someday you will be able to type "make config" 8-)
|
|
|
|
There is a number of programs on tsx-11.mit.edu in
|
|
/pub/linux/packages/laptops/ that you may find useful. These
|
|
range from PCMCIA Ethercard drivers to programs that communicate
|
|
with the PCMCIA controller chip. Note that these drivers are
|
|
usually tied to a specific PCMCIA chip (ie. the intel 82365
|
|
or the TCIC/2) On a brighter note, I know that people have used the
|
|
Linksys/D-Link 650 PCMCIA Ethernet PC Card with both controller
|
|
chipsets, so it *can* be done. I have also seen reports of
|
|
people using the IBM Credit Card Adapter for Ethernet with the
|
|
intel 82365 chip. This is all just from following the LAPTOPS
|
|
channel.
|
|
|
|
The 3c589 from 3Com is supposed to look a lot like a 3c509.
|
|
|
|
Anyway, the PCMCIA driver problem isn't specific to the Linux world.
|
|
It's been a real disaster in the MS-DOS world. In that world
|
|
people expect the hardware to work if they just follow the manual.
|
|
They might not expect it to interoperate with any other hardware
|
|
or software, or operate optimally, but they do expect that the
|
|
software shipped with the product will function. Many PCMCIA
|
|
adaptors don't pass this test.
|
|
|
|
7.03 Option 3 -- ISA Ethercard in the Docking Station.
|
|
|
|
I recommend the third solution. Docking stations for laptops typically
|
|
cost about $250 and provide two full-size ISA slots, two serial and one
|
|
parallel port. Most (all?) docking stations are powered off of the
|
|
laptop's batteries, and a few allow adding extra batteries in the
|
|
docking station if you use short ISA cards. You can add an inexpensive
|
|
ethercard and enjoy full-speed ethernet performance.
|
|
|
|
7.04 Option 4 -- Pocket / parallel port adaptors.
|
|
|
|
The "pocket" ethernet adaptors may also fit your need.
|
|
Until recently they actually costed more than a docking station and
|
|
cheap ethercard, and most tie you down with a wall-brick power supply.
|
|
At present, you can choose from the D-Link, or the RealTek adaptor.
|
|
Most other companies, especially Xircom, treat the programming
|
|
information as a trade secret, so support will likely be slow in
|
|
coming.
|
|
|
|
You can sometimes avoid the wall-brick with the adaptors by buying
|
|
or making a cable that draws power from the laptop's keyboard
|
|
port. (This is mentioned in the info. for the AT-Lan-Tec unit.)
|
|
|
|
The keyboard pinouts (5 pin DIN) are as follows:
|
|
|
|
Signal/Function Pin #
|
|
--------------- -----
|
|
KEYCLK (clock) 1
|
|
KEYDAT (data) 2
|
|
N/C 3
|
|
Ground 4
|
|
+5 V 5
|
|
|
|
A quick check with a voltmeter will verify which pins are 4 and 5
|
|
if you are not sure.
|
|
8 Frequently asked questions
|
|
|
|
Here are some of the more frequently asked questions about using
|
|
Linux with an Ethernet connection. Some of the more specific
|
|
questions are sorted on a "per manufacturer basis" and are listed
|
|
in the "Troubleshooting" section. (section 6). However, since this
|
|
document is basically "old" by the time you get it, any "new" problems
|
|
will not appear here instantly. For these, I suggest that you make
|
|
efficient use of your newsreader. For example, nn users would type
|
|
nn -xX -s'3c'
|
|
to get all the news articles in your subscribed list that have
|
|
"3c" in the subject. (ie. 3com, 3c509, 3c503, etc.)
|
|
The moral: Read the man page for your newsreader.
|
|
|
|
8.01 Just the FAQ's ma'am -- just the FAQ's.
|
|
|
|
Q: I heard that there is an alpha driver available for my card.
|
|
Where can I get it?
|
|
|
|
A: Assuming that it is a djb driver, it will be on ftp.super.org
|
|
in the /pub/linux/ area. Things change here quite frequently,
|
|
so just look around for it. There is usually only about 3
|
|
subdirs, so you should be able to find it. Now, if it really
|
|
is an alpha, or pre-alpha driver, then please treat it as
|
|
such. In other words, don't complain because you can't figure
|
|
out what to do with it. If you can't figure out how to install
|
|
it, then you probably shouldn't be testing it. Also, if it brings
|
|
your machine down, don't complain. Instead, send us a well
|
|
documented bug report, or even better, a patch!
|
|
|
|
Q: Is there token ring support for Linux?
|
|
|
|
A: No, there is no token ring support in Linux. To support token ring
|
|
requires more than only a writing a device driver, it also requires
|
|
writing the source routing routines for token ring. Given that
|
|
token ring is expensive, not fast, and will probably be swept away
|
|
by 100baseVG in a few months, it doesn't seem worth it to write
|
|
a driver. In case anyone wants to, I looked at writing a token ring
|
|
device driver, and concluded that the hardware interface
|
|
wasn't too difficult to do, but writing the support for source
|
|
routing would take significantly longer than I was willing to spend
|
|
on an expensive and dying technology.
|
|
|
|
Alan Cox adds: "It will require [...] changes to the bottom socket
|
|
layer to support 802.2 and 802.2 based TCP/IP. Don't expect
|
|
anything soon."
|
|
|
|
Q: Is there FDDI support for Linux?
|
|
|
|
A: No, there is no Linux driver for any FDDI boards. I come from a
|
|
place with supercomputers, so an external observer might think
|
|
FDDI would be high on my list. But FDDI never delivered end-to-end
|
|
throughput that would justify its cost, and it seems to be a nearly
|
|
abandoned technology now that 100base{X,Anynet} seems imminent.
|
|
(And yes, I know you can now get FDDI boards for <$1K. That
|
|
seems to be a last-ditch effort to get some return on the
|
|
development investment. Where is the next generation of FDDI
|
|
going to come from?)
|
|
|
|
Q: Can I link 10BaseT (RJ45) based systems together without a hub?
|
|
|
|
A: You can link 2 machines easily, but no more than that, without
|
|
extra devices/gizmos. See section 4 on wiring -- it explains
|
|
how to do it. And no, you can't hack together a hub just by
|
|
crossing a few wires and stuff. It's pretty much impossible
|
|
to do the collision signal right without duplicating a hub.
|
|
|
|
Q: Is there IPX or Novell support available for Linux?
|
|
|
|
A: Alan Cox writes: "The novell protocols are available from novell
|
|
for various amounts. IPX is freely documented. SPX is about $1000
|
|
but I'm told Xerox SPP is identical. _PLEASE_ has anyone got any
|
|
freely distributable Xerox SPP code/documentation? The novell
|
|
server spec costs you $15000 + royalties providing you only
|
|
want to write a client, or $30000 + royalties otherwise. Needless
|
|
to say the final output has to be binary only and subject to a
|
|
novell license. Reading their license rules by my interpretation
|
|
its also impossible for us to do because you would seem to have
|
|
to bar disassembly of your final result, which is not allowed
|
|
in the EEC.
|
|
|
|
Bits of NCP are known, and I hope eventually enough will be known
|
|
to write limited NCP support into Linux, for the moment I'm poking
|
|
around at IPX, tho this will have to wait until the new network
|
|
code is finished.
|
|
|
|
An Alpha test IPX protocol layer is available from me (Alan)
|
|
for pl14 or higher. People are also exploring the issue of NCP and
|
|
the new Dr Dobbs journal article on the innards of netware has
|
|
provided a core of good information."
|
|
|
|
As an alternative, Miquel van Smoorenburg suggests the following:
|
|
"It _is_ possible to set up a dedicated PC running both novell and
|
|
the PD SOSS server and let it gateway from NFS to novell. This way
|
|
it is possible to mount the Novell drives on the Unix client.
|
|
|
|
SOSS is a PD (perhaps with some restrictions, but freely available)
|
|
NFS server for DOS. It includes the PC/IP TCP/IP implementation
|
|
and runs on a packet driver. I have run both a Novell client
|
|
(with PDIPX, a Packet Driver IPX) and this SOSS server together
|
|
successfully."
|
|
|
|
You can get "Stan's Own Server System" from the following location:
|
|
hilbert.wharton.upenn.edu:pub/tcpip/soss.zip
|
|
Note that this version has the IP bugs fixed and the subdirs
|
|
with extensions bug fixed. Some of the soss.zoo archives do
|
|
not contain these fixes.
|
|
|
|
Q: What needs to be done so that Linux can run two ethernet cards?
|
|
|
|
A: The easiest solution is to get 0.99pl13 or newer, as the hooks for
|
|
multiple ethercards are all there.
|
|
You can enable additional ethercards with LILO parameters such as:
|
|
|
|
lilo: linux ether=5,0x300,0,1,eth0 ether=15,0x280,eth1
|
|
|
|
These boot time arguments can be made permanent so that you
|
|
don't have to re-enter them every time. See the LILO manual.
|
|
|
|
Q: Okay, I can run 2 cards -- can I run Linux as a gateway
|
|
between two networks?
|
|
|
|
A: This is really a question for the NET-HOWTO, but it is
|
|
answered here anyways: Charles Hedrick (aka Mr. Slip)
|
|
had this to say:
|
|
|
|
"Yes, however I'm a bit nervous about doing it. The problem isn't
|
|
functionality -- there's IP forwarding code, and as far as I know,
|
|
it works. Some people do use it. However routers need to be
|
|
particularly careful to avoid creating network problems such as
|
|
"meltdowns." The Linux IP layer doesn't have quite enough of these
|
|
protective features. It will only cause trouble if other hosts on
|
|
your network are misconfigured, and even then it probably won't
|
|
cause much trouble (assuming that only systems actually acting as
|
|
gateways are built with IP_FORWARD enabled). But I'd still rather
|
|
use a router that met all of the requirements of the host and
|
|
router requirements in the RFC's. (Note that not all other Unix
|
|
implementations do either. I'm concerned about things like not
|
|
sending ICMP responses to messages that arrive as media
|
|
broadcasts. 386BSD looks OK, but older BSD-based implementations
|
|
often didn't do all of these checks.)
|
|
|
|
It depends a lot on what the network is like and how critical it is.
|
|
For a home setup with a couple of hosts, I see no problem at all.
|
|
But I would not consider using Linux as a router on a large
|
|
campus network at the moment. I still think that by release 1.0,
|
|
Linux will be a reasonably well-behaved host. But I think use
|
|
as a router in critical situations should wait until somebody
|
|
has checked the ip and icmp modules for compliance with RFC 1009
|
|
and a few other specs."
|
|
|
|
Q: I have /dev/eth0 as a link to /dev/xxx. Is this right?
|
|
|
|
A: Contrary to what you have heard, the files in /dev/* are not used.
|
|
I originally thought that they might be an OK idea. I've since
|
|
concluded that they won't work, at least in the documented form.
|
|
|
|
Q: Should I disable trailers when I "ifconfig" my ethercard?
|
|
|
|
A: You can't disable trailers, and you shouldn't want to.
|
|
'Trailers' are a hack to avoid data copying in the
|
|
networking layers. The idea was to use a trivial
|
|
fixed-size header of size 'H', put the variable-size header
|
|
info at the end of the packet, and allocate all packets
|
|
'H' bytes before the start of a page. While it was a good
|
|
idea, it turned out to not work well in practice.
|
|
If someone suggests the use of '-trailers', note that it
|
|
is the equivalent of sacrificial goats blood. It won't do
|
|
anything to solve the problem, but if problem fixes itself then
|
|
someone can claim deep magical knowledge.
|
|
|
|
9 Miscellaneous.
|
|
|
|
Any other associated stuff that didn't fit in anywhere else gets
|
|
dumped here. It may not be relevant, and it may not be of general
|
|
interest but it is here anyway.
|
|
|
|
9.01 Bad Vendors
|
|
|
|
#define SOAPBOX
|
|
|
|
There used to be some horror stories here about dealings with
|
|
Cabletron and Xircom. They were pretty ugly and gruesome.
|
|
Basically these companies are the ethernet equivalent of
|
|
what Diamond is to XFree86. They do not want to release
|
|
vital information on low-level programming of their hardware.
|
|
For something like Linux, where the source code for everything
|
|
is out in the open, this makes their hardware difficult or
|
|
impossible to use. However, like Diamond, when confronted
|
|
with the fact that they are losing sales from Linux/BSD users,
|
|
they basically shrug it off, saying that it is only a small
|
|
percentage of the total sales. If you can afford the time,
|
|
drop these vendors a note (via e-mail or snail-mail) and tell
|
|
them politely that the fact that they don't support open
|
|
software systems such as Linux has forced you to exclude them
|
|
from the vendors that you are purchasing hardware from. It may
|
|
not make any immediate difference, but it might make you feel
|
|
better. Besides, a few seconds of your time is a cheap price
|
|
to pay for *all* that free Linux software you are using. 8-)
|
|
|
|
#undef SOAPBOX
|
|
|
|
9.02 Closing
|
|
|
|
If you have found any glaring typos, or outdated info in this
|
|
document, please let one of us know. It's getting big, and it
|
|
is easy to overlook stuff.
|
|
|
|
Paul Gortmaker <gpg109@rsphy1.anu.edu.au>
|
|
Donald J. Becker <becker@super.org>
|
|
|
|
=========== end of Ethernet HOWTO ============
|
|
|