Debugging NE2000 Ethernet connections

First, run ETHTEST on two nodes. Make sure both nodes show up in the matrix of dots. Then do a block transmit test on one of the nodes. When asked for the target node give the other computer's node number. 100 blocks should be sent. The target computer will report each block as it receives it. If the target gets all blocks then the hardware is ready for the network.

If the computer hangs when the main ETHTEST screen comes up, and even Ctl-Alt-Del does not work, then try running ETHTEST in the NE1000 mode, or NE2000/8bit slot, or NE2000 type:1. If Ctl-Alt-Del works then there may be a cable problem - either no terminator or the cable is not attached to the card.

Remember, ETHTEST checks the hardware directly and does not need the network to be setup at all. If this test fails you have a hardware problem and LBL will surely not work until you correct the problem! Look at POSSIBILITY 2, and POSSIBILITY 3.

If ETHTEST runs and can succesfully transmit between the nodes, then LBL should work. If it is not working it is most likely due to a setup problem.

One utility we provide which might be helpful is WATCH.COM in the \LBL\DIAGNOSE subdirectory. To use this, put the word "DEBUG" on the ETH_LINK line in AUTOEXEC.BAT, then reboot.

Just add the word "debug" to the end of this line in AUTOEXEC.BAT:

        C:\LBL\ETH_LINK INT?  DEBUG

Then run WATCH on one computer:

        C\LBL\DIAGNOSE> WATCH

Go to the other computer and try to do a directory of a drive on the computer running watch. Notice if WATCH got any IRQs (indicated by the ".." changing to a number). Then do the same test the other direction. You may be able to determine which computer is giving you the trouble by doing this test.

If you do not get IRQs one direction, but do get them the other direction, at least we have narrowed down the problem. If you get no IRQs on a computer, then it is probably that computer's IRQ. Look at POSSIBILITY 2 below. Or it is a setup problem on the other computer. Look at POSSIBILITY 1. If you get IRQs both directions, but the "busy" counter has activity, then it is POSSIBILITY 1 on the computer getting "busy", or you may merely need to reboot both machines because the network is in an unstable state due to leftovers from a prior (already corrected by you) problem.

POSSIBILITY 1:

First, make sure each node knows how to reach the other. We have found this to be the most common problem. To check this, run LBL.COM on both computers. Use the right arrow key to select "Connections" and then hit . You should see both computers listed on this screen (ie, their node name). Lets say you used node numbers 1 and 2. Lets also say you are looking at the "Connections" screen on node 1. Then on the row for node 2 you should see the "Use Link Module" columns filled in with the appropriate method to reach that node. In the case of ethernet it must say "50 ETHERNET". If this information is not there then select "Enter", move to the proper row/column, type in 50 as the module number, or type "ETHERNET" as the module name, then hit the Escape key, select "Save Defaults", and hit . Go to the other node and verify it is also setup in the same way. But remember, you are looking at the world on node 2 from its point of view so the row you need to look at is the row for node 1 (because node 1 is the node you are attempting to reach). This should have "50 ETHERNET" for node 2 to know to reach node 1 it must use the ethernet driver. What you are doing here is telling each computer what method to use to reach a particular node.

If the "Connection" is blank, but "Load Defaults" fills in the data, then you may have two copies of a file named "CONNLIST.x". Make sure only one copy of these files exist, and they are in the \LBL directory, not the root directory.

Do not use the "LINKTO:ALL" parameter on ETH_LINK since some versions have a bug which prevents the network from operating.

POSSIBILITY 2:

The other, second most likely cause of trouble is an IRQ problem. If ETHTEST works then this is not the problem. But if ETHTEST fails to see all nodes (except itself) then this is a possibility. You should try experimenting with other IRQ selections. Remember to tell your ETH_LINK which IRQ you have jumpered your hardware for.

Most ethernet cards are shipped with IRQ 3 selected. If you have not switch the card to something else then you should know that IRQ 3 is also used by COM2 and COM4. If a mouse driver, for example, loads on COM2 then it will effectively steal IRQ 3 away from the ethernet card. IRQ 4 has the same problem for COM1 and COM3. Other possible conflicts are CDROMS, sound cards, FAX cards, scanners, bus mice, and some video cards. But the printer ports almost never cause an IRQ conflict. Most documentation will tell you IRQ 7 and IRQ 5 are dedicated to the printer ports. What they fail to mention is that the printer ports will never use their IRQs. The only exceptions to this are programs such as Litthe Big LAN when using the parallel ports to link, or some other file transfer programs, or a few printer spoolers. So, it is almost always safe to use the printer IRQs for ethernet cards.

POSSIBILITY 3:

Thi I/O address selection is sometimes a problem. If you use I/O address 300H then you are usually safe. But some CDROM boards will use the same address, or may overlap. NE2000 cards use 32 consecutive i/o addresses. So if your CDROM is at 310H, and your NE2000 card is at 300H, the ethernet card occupies some or the same i/o space (310H-31FH). Another problem sometimes comes from i/o address 360H. LPT1 is often at 378H, so the network may work until anyone prints to LPT1. Then the ethernet is suddenly dead. This is because writing to LPT1 will reset any NE2000 or NE1000 card residing at 360H. Again, the only way to tell if you have an i/o address conflict is to try a few combinations.

GENERAL

Make sure the network loads. It is possible AUTOEXEC.BAT has a line which exits to a secondary batch and never returns. If this line is located above the network lines then the network never loads even though the proper lines are there. Make sure you see our sign on message with version and serial number.

FINAL NOTE:

Since there are so many combinations to try it is usually easier to get the network working and then work backwards from there. So you might have to remove or disable other hardware to be sure nothing else is in the way. Also remove (or REM out) as much as is possible in CONFIG.SYS and AUTOEXEC.BAT. Once, working, restore your system item by item until the problem shows up.


P.S. The message "unattached channel" means that NET21 has not
     loaded in AUTOEXEC.BAT.  Put a PAUSE statement before and
     after NET21 and see if any error messages print out.

     ALSO: Make sure terminators are on the cable.

Top of Tech Help -or- Table of Contents -or- Top of Form