Previous Next Contents

3. 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'. 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.

3.1 Alpha Drivers -- Getting and Using them

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:

Don's Linux Home Page

for the latest dirt on what is new and upcoming.

3.2 Using More than one Ethernet Card per Machine

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.

3.3 Poor NE2000 Clones

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

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.

3.4 Problems with NE1000 / NE2000 cards (and clones)

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:

3.5 Problems with WD80*3 cards

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

3.6 Problems with 3Com cards

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.

3.7 Problems with Hewlett Packard Cards

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.

3.8 FAQs Not Specific to Any Card.

Ethercard is Not Detected at Boot.

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.

Shared Memory ISA cards in PCI Machine

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.

Asynchronous Transfer Mode (ATM) Support

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:

Linux ATM Support

FDDI Support

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?)'

Ethernet Cards for Linux on Alpha/AXP PCI Boards

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().

Linking 10BaseT without a Hub

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.

SIOCSIFxxx: No such device

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.

SIOCSFFLAGS: Try again

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.

Link UNSPEC and HW-addr of 00:00:00:00:00:00

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.

Huge Number of RX and TX Errors

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.

Entries in /dev/ for Ethercards

I 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.

Linux and ``trailers''

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.

Access to the raw Ethernet Device

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.


Previous Next Contents