Debugging Packet Drivers Connections

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

If PKTEST 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 PKT_LINK line in AUTOEXEC.BAT, then reboot.

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

        C:\LBL\PKT_LINK  DEBUG

        C\LBL\DIAGNOSE> WATCH  IRQx

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

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 packet drivers it must say "50 PDRIVER". If this information is not there then select "Enter", move to the proper row/column, type in 50 as the module number, or type "PDRIVER" 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. This should have "50 PDRIVER" for node 2 to reach node 1. What you are doing here is telling each computer what method to use to reach a particular node.

POSSIBILITY 2:

The other, second most likely cause of trouble is an IRQ problem. If PKTEST works then this is not the problem. But if PKTEST fails to see all nodes (except itself) then this is a possibility. You should try experimenting with other irq selections. Remember to tell your packet driver which irq you have jumpered your hardware for. Some software irq selectable cards are shipped with packet drivers that can read the irq setting off of the card, so you will not need to tell those packet drivers. But if your card is not software jump-able, you must tell the packet driver which irq to use. The syntax for doing so varies among drivers, but most will display a help screen if you type the name of the driver with no parameters.

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, for example, 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. But not all ethernet cards have this problem since many only require 16 addresses (10H).

Again, the only way to tell if you have an i/o address conflict is to try a few combinations.

One more thing to try - run PKTEST after you first boot, and then exit. See if the LAN then works. If so, we have a utility you need to download.

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.

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