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'. 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.
I heard that there is an updated or alpha driver available for my card. Where can I get it?
The newest of the `new' drivers can be found on Donald's new
ftp site: cesdis.gsfc.nasa.gov
in the
/pub/linux/
area. Things
change here quite frequently, so just look around for it.
There is still all the stuff on the old ftp site ftp.super.org
in /pub/linux
, but this is not being actively maintained,
and hence will be of limited value to most people.
Note that most of the `useable' alpha drivers have been
included in the standard kernel source tree. When running
make config
you will be asked if you want to be offered
ALPHA test drivers.
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!
People reading this while net-surfing may want to check out:
for the latest dirt on what is new and upcoming.
What needs to be done so that Linux can run two ethernet cards?
The hooks for multiple ethercards are all there. However, note that only one ethercard is auto-probed for by default. This avoids a lot of possible boot time hangs caused by probing sensitive cards.
There are two ways that you can enable auto-probing for
the second (and third, and...) card. The easiest
method is to pass boot-time arguments to the kernel,
which is usually done by LILO. Probing for the
second card can be achieved by using a boot-time argument
as simple as ether=0,0,eth1
. In this
case eth0
and eth1
will be assigned in the order
that the cards are found at boot. Say if you want
the card at 0x300
to be eth0
and
the card at 0x280
to be eth1
then you could use
LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
The ether=
command accepts more than the IRQ + i/o
+ name shown above. Please have a look at
Passing Ethernet Arguments...
for the full syntax, card specific parameters, and LILO tips.
These boot time arguments can be made permanent so that you
don't have to re-enter them every time. See the LILO
configuration option `append
' in the LILO manual.
The second way (not recommended) is to edit the file
Space.c
and replace the 0xffe0
entry for the
i/o address with a zero. The 0xffe0
entry tells it
not to probe for that device -- replacing it with a zero
will enable autoprobing for that device.
If you really need more than four ethernet
cards in one machine, then you can add an eth4
entry
and an eth5
entry and so on.
Note that if you are intending to use Linux as a gateway between two networks, you will have to re-compile a kernel with IP forwarding enabled. Usually using an old AT/286 with something like the `kbridge' software is a better solution.
If you are viewing this while net-surfing, you may wish to look at a mini-howto Donald has on his WWW site. Check out Multiple Ethercards .
For module users with 8390 based cards, you can have a single module control multiple cards as well. Please see 8390 Based Cards as Modules for module specific information about using multiple cards.
Here is a list of some of the NE-2000 clones that are known to
have various problems. Most of them aren't fatal. In the case
of the ones listed as `bad clones' -- this usually indicates that
the cards don't have the two NE2000 identifier bytes. NEx000-clones
have a Station Address PROM (SAPROM) in the packet buffer memory space.
NE2000 clones have 0x57,0x57
in bytes 0x0e,0x0f
of the SAPROM, while other supposed NE2000 clones must be
detected by their SA prefix.
This is not a comprehensive list of all the NE2000 clones that
don't have the 0x57,0x57
in bytes 0x0e,0x0f
of the SAPROM. There are probably hundreds of them. If you
get a card that causes the driver to report an `invalid
signature' then you will have to add your cards signature
to the driver. The process for doing this is described
below.
Accton NE2000 -- might not get detected at boot, see below.
Aritsoft LANtastic AE-2 -- OK, but has flawed error-reporting registers.
AT-LAN-TEC NE2000 -- clone uses Winbond chip that traps SCSI drivers
ShineNet LCS-8634 -- clone uses Winbond chip that traps SCSI drivers
Cabletron E10**, E20**, E10**-x, E20**-x -- bad clones, but the driver checks for them. See E10** .
D-Link Ethernet II -- bad clones, but the driver checks for them. See DE-100 / DE-200 .
DFI DFINET-300, DFINET-400 -- bad clones, but the driver checks for them. See DFI-300 / DFI-400
EtherNext UTP8, EtherNext UTP16 -- bad clones, but the driver checks for them.
Problem: NE*000 card hangs machine, sometimes with a `DMA conflict' message, sometimes completely silently.
Reason: There were some bugs in the driver and the upper networking layers that caused this. They have been fixed in kernels v1.2.9 and above. Upgrade your kernel.
Problem: NE*000 card hangs machine during NE probe, or can not read station address properly.
Reason: Kernels previous to v1.3.7 did not fully reset the card after finding it at boot. Some cheap cards are not left in a reasonable state after power-up and need to be fully reset before any attempt is made to use them. Also, a previous probe may have upset the NE card prior to the NE probe taking place. In that case, look in to using the ``reserve='' boot keyword to protect the card from other probes.
Problem: NE*000 driver reports `not found (no reset ack)' during boot probe.
Reason: This is related to the above change. After the initial verification that an 8390 is at the probed i/o address, the reset is performed. When the card has completed the reset, it is supposed to acknowedge that the reset has completed. Your card doesn't, and so the driver assumes that no NE card is present.
Solution:
Change the two lines as shown below in drivers/net/ne.c
- printk(" not found (no reset ack).\n"); - return ENODEV; + printk(" (warning: no reset ack)"); + break;
This will allow the card detection to continue, even if your card doesn't ACK the reset.
Problem: NE*000 card hangs machine at first network access.
Reason: This problem has been reported for kernels as old as 1.1.57 to the present. It appears confined to the software configurable clone cards. It appears that they expect to be initialized in some special way.
Solution: Several people have reported that running the supplied DOS software config program and/or the supplied DOS driver prior to warm booting (i.e. loadlin or the `three-finger-salute') into linux allowed the card to work. This would indicate that these cards need to be initialized in a particular fashion, slightly different than what the present Linux driver does.
Problem:
NE*000 ethercard at 0x360
doesn't get detected anymore.
Reason:
Recent kernels ( > 1.1.7X) have more sanity checks with respect
to overlapping i/o regions. Your NE2000 card is 0x20
wide in
i/o space, which makes it hit the parallel port at 0x378
.
Other devices that could be there are the second floppy
controller (if equipped) at 0x370
and the secondary
IDE controller at 0x376--0x377
.
If the port(s) are already registered by another driver, the
kernel will not let the probe happen.
Solution:
Either move your card to an address like 0x280, 0x340, 0x320
or compile without parallel printer support.
Problem: Network `goes away' every time I print something (NE2000)
Reason: Same problem as above, but you have an older kernel that doesn't check for overlapping i/o regions. Use the same fix as above, and get a new kernel while you are at it.
Problem: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz)
Reason:
First off, do you have a NE1000 or NE2000 card at the addr. 0xNNN?
And if so, does the hardware address reported look like a valid
one? If so, then you have a poor NE*000 clone. All NE*000 clones
are supposed to have the value 0x57
in bytes 14 and 15 of the
SA PROM on the card. Yours doesn't -- it has `yy zz' instead.
Solution: The driver (/usr/src/linux/drivers/net/ne.c) has a "Hall of Shame" list at about line 42. This list is used to detect poor clones. For example, the DFI cards use `DFI' in the first 3 bytes of the prom, instead of using 0x57 in bytes 14 and 15, like they are supposed to.
You can determine what the first 3 bytes of your card PROM are by adding a line like:
printk("PROM prefix: %2.2x %2.2x %2.2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);
into the driver, right after the error message you got above, and just before the "return ENXIO" at line 227.
Reboot with this change in place, and after the detection fails, you will get the three bytes from the PROM like the DFI example above. Then you can add your card to the bad_clone_list[] at about line 43. Say the above line printed out:
PROM prefix: 0x3F 0x2D 0x1C
after you rebooted. And say that the 8 bit version of your card was called the "FOO-1k" and the 16 bit version the "FOO-2k". Then you would add the following line to the bad_clone_list[]:
{"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},
Note that the 2 name strings you add can be anything -- they are just printed at boot, and not matched against anything on the card. You can also take out the "printk()" that you added above, if you want. It shouldn't hit that line anymore anyway. Then recompile once more, and your card should be detected.
Problem:
Errors like 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. (Note: The DMA address check is not done
by default as of v1.2.4 for performance reasons. Enable it with
the `NE_SANITY' define in ne.c
if you want the check done.)
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 in 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.
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.
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 0x340
. Alternatively, you
can use the device registrar implemented in 0.99pl13 and later
kernels.
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.
Reason: 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.
Reason: No, that's really during the silent SCSI probe, and it's the same problem as above.
Problem: NE2000 not detected at boot - no boot messages at all
Donald writes: `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:
Problem: A WD80*3 is falsely detected. Removing the sound or MIDI card eliminates the `detected' message.
Reason: Some MIDI ports happen to produce the same checksum as a WD ethercard.
Solution: Update your ethercard driver: new versions include an additional sanity check. If it is the midi chip at 0x388 that is getting detected as a WD living at 0x380, then you could also use:
LILO: linux reserve=0x380,8
Problem: You get messages such as the following with your 80*3:
eth0: bogus packet size, status = NNNN 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@cesdis.gsfc.nasa.gov - Take particular note of the shared memory location.
Problem: WD80*3 will not get detected at boot.
Reason: Earlier versions of 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. 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 Probed Addresses You can also point the mcd driver off in another direction by a boot-time parameter (via LILO) such as:
mcd=0x200,12
Problem: Old wd8003 and/or jumper-settable wd8013 always get the IRQ wrong.
Reason: The old wd8003 cards and jumper-settable wd8013 clones don't have the EEPROM that the driver can read the IRQ setting from. If the driver can't read the IRQ, then it tries to auto-IRQ to find out what it is. And if auto-IRQ returns zero, then the driver just assigns IRQ 5 for an 8 bit card or IRQ 10 for a 16 bit card.
Solution: Avoid the auto-IRQ code, and tell the kernel what the IRQ that you have jumpered the card to is via a boot time argument. For example, if you are using IRQ 9, using the following should work.
LILO: linux ether=9,0,eth0
Problem: The 3c503 picks IRQ N, but this is needed for some other device which needs IRQ N. (eg. CD ROM driver, modem, 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. Very old drivers used to pick the IRQ line at boot-time, and the current driver (0.99pl12 and newer) chooses when the card is open()/ifconfig'ed.
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
Problem: 3c503: configured interrupt X invalid, will use autoIRQ.
Reason: The 3c503 card can only use one of IRQ{5, 2/9, 3, 4} (These are the only lines that are connected to the card.) If you pass in an IRQ value that is not in the above set, you will get the above message. Usually, specifying an interrupt value for the 3c503 is not necessary. The 3c503 will autoIRQ when it gets ifconfig'ed, and pick one of IRQ{5, 2/9, 3, 4}.
Solution: Use one of the valid IRQs listed above, or enable autoIRQ by not specifying the IRQ line at all.
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
With kernels 1.3.42 and newer, you can specify the
AUI port when loading as a module as well. Just append
xcvr=1
to the insmod
command line along with
your i/o and irq values.
Also note that kernel revisions 1.00 to 1.03 had an interesting `feature'. They would switch to the AUI port when the internal transceiver failed. This is a problem, as it will never switch back if for example you momentarily disconnect the cable. Kernel versions 1.04 and newer only switch if the very first Tx attempt fails.
Problem: HP Vectra using built in AMD LANCE chip gets IRQ and DMA wrong.
Solution: The HP Vectra uses a different implementation to the standard HP-J2405A. The `lance.c' driver used to always use the value in the setup register of an HP Lance implementation. In the Vectra case it's reading an invalid 0xff value. Kernel versions newer than about 1.1.50 now handle the Vectra in an appropriate fashion.
Problem: HP Card is not detected at boot, even though kernel was compiled with `HP PCLAN support'.
Solution: You probably have a HP PCLAN+ -- note the `plus'. Support for the PCLAN+ was added to mid/late versions of 1.1. Recompile a (possibly newer) kernel with support for the HP PCLAN+ and you should be in business.
The usual reason for this is that people are using a kernel that does not have support for their particular card built in. If you are using a pre-compiled kernel that is part of a distribution set, then check the documentation to see which kernel you installed, and if it was built with support for your particular card. If it wasn't, then your options are to try and get one that has support for your card, or build your own.
It is usually wise to build your own kernel with only the drivers you need, as this cuts down on the kernel size (saving your precious RAM for applications!) and reduces the number of device probes that can upset sensitive hardware. Building a kernel is not as complicated as it sounds. You just have to answer yes or no to a bunch of questions about what drivers you want, and it does the rest.
The next main cause is having another device using part
of the i/o space that your card needs. Most cards are
16 or 32 bytes wide in i/o space. If your card is set
at 0x300 and 32 bytes wide, then the driver will ask
for 0x300-0x31f. If any other device driver has registered
even one port anywhere in that range, the probe will not
take place at that address and the driver will silently
continue to the next of the probed addresses. So, after
booting, do a cat /proc/ioports
and verify that the
full iospace that the card will require is vacant.
Another problem is having your card jumpered to an i/o
address that isn't probed by default. There is a list
probed addresses
for each card
in this document. Even if the i/o setting of your card is
not in the list of porbed addresses, you can supply
it at boot with the ether=
command as described in
Passing Ethernet Arguments...
ifconfig
reports the wrong i/o address for the card.No it doesn't. You are just interpreting it incorrectly.
This is not a bug, and the numbers reported are correct. It just
happens that some 8390 based cards (wd80x3, smc-ultra, etc) have the
actual 8390 chip living at an offset from the first assigned i/o port.
Try cd /usr/src/linux/drivers/net;grep NIC_OFFSET *.c|more
to see what is going on. This is the value stored in
dev->base_addr
, and is what ifconfig
reports. If you
want to see the full range of ports that your card uses, then try
cat /proc/ioports
which will give the numbers you expect.
This will usually show up as reads of lots of 0xffff
values.
No shared memory cards of any type will work in a PCI machine
unless you have the PCI ROM BIOS/CMOS SETUP configuration set
properly. You have to set it to allow shared memory access
from the ISA bus for the memory region that your card is trying
to use. If you can't figure out which settings are applicable
then ask your supplier or local computer guru.
Werner Almesberger has been playing around with ATM support for linux. He has been working with the Efficient Networks ENI155p board ( Efficient Networks ) and the Zeitnet ZN1221 board ( Zeitnet ).
Werner says that the driver for the ENI155p is rather stable, while the driver for the ZN1221 is presently unfinished.
Check the latest/updated status at the following URL:
Is there FDDI support for Linux?
Donald writes: `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?)'
At present only the depca, de4x5 and all the 8390 drivers (wd, smc-ultra, ne, 3c503, e2100, ac3200, hp, hp-plus) have been made `architecture independent' so as to work on the DEC Alpha CPU based systems.
Note that the changes that are required aren't that complicated. You only need to do the following:
-multiply all jiffies
related values by HZ/100 to account
for the different HZ value that the Alpha uses.
(i.e timeout=2;
becomes timeout=2*HZ/100;
)
-replace any i/o memory (640k to 1MB) pointer dereferences with the appropriate readb() writeb() readl() writel() calls, as shown in this example.
- int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base);
-replace all memcpy() calls that have i/o memory as source or
target destinations with the appropriate one of
memcpy_fromio()
or memcpy_toio()
.
Can I link 10BaseT (RJ45) based systems together without a hub?
You can link 2 machines easily, but no more than that, without extra devices/gizmos. See Twisted Pair -- 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.
I get a bunch of `SIOCSIFxxx: No such device' messages at boot, followed by a `SIOCADDRT: Network is unreachable' What is wrong?
Your ethernet device was not detected at boot, and when
ifconfig
and route
are run, they have no device
to work with. Use dmesg | more
to review the
boot messages and see if there are any messages about
detecting an ethernet card.
I get `SIOCSFFLAGS: Try again' when I run `ifconfig' -- Huh?
Some other device has taken the IRQ that your ethercard
is trying to use, and so the ethercard can't use the IRQ.
You don't necessairly need to reboot to resolve this, as
some devices only grab the IRQs when they need them and
then release them when they are done. Examples are some
sound cards, serial ports, floppy disk driver, etc. You
can type cat /proc/interrupts
to see which interrupts
are presently in use. Most of the
Linux ethercard drivers only grab the IRQ when they are
opened for use via `ifconfig'. If you can get the other
device to `let go' of the required IRQ line, then you
should be able to `Try again' with ifconfig.
When I run ifconfig with no arguments, it reports that LINK is UNSPEC (instead of 10Mbs Ethernet) and it also says that my hardware address is all zeros.
This is because people are running a newer version of the `ifconfig' program than their kernel version. This new version of ifconfig is not able to report these properties when used in conjunction with an older kernel. You can either upgrade your kernel, `downgrade' ifconfig, or simply ignore it. The kernel knows your hardware address, so it really doesn't matter if ifconfig can't read it.
When I run ifconfig with no arguments, it reports that I have a huge error count in both rec'd and transmitted packets. It all seems to work ok -- What is wrong?
Look again. It says RX packets
big number PAUSE
errors 0
PAUSE dropped 0
PAUSE overrun 0
.
And the same for the TX
column.
Hence the big numbers you are seeing are the total number of
packets that your machine has rec'd and transmitted.
If you still find it confusing, try typing
cat /proc/net/dev
instead.
/dev/
for EthercardsI have /dev/eth0 as a link to /dev/xxx. Is this right?
Contrary to what you have heard, the files in /dev/* are not used.
You can delete any /dev/wd0, /dev/ne0
and similar entries.
Should I disable trailers when I `ifconfig' my ethercard?
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.
How do I get access to the raw ethernet device in linux, without going through TCP/IP and friends?
int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
This gives you a socket receiving every protocol type.
Do recvfrom()
calls to it and it will fill the sockaddr
with device type in sa_family and the device name in the
sa_data array. I don't know who originally invented
SOCK_PACKET for Linux (its been in for ages) but its superb stuff.
You can use it to send stuff raw too via sendto()
calls.
You have to have root access to do either of course.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter