Skip to main content
Skip table of contents

Ethernet Troubleshooting (App Note)

These are the most common problems for not being able to connect to a LabJack device on your network, and how to solve them.  Many of these also apply to WiFi connections, but there are additional T7-Pro WiFi specific troubleshooting tips at the end of Setup WiFi and Ethernet for the T7, T4, and T7-Pro App Note.

#1: Some Networking Basics

Make sure you are up-to-speed on these basic items first, and in the event you need to contact us you can start by letting us know you have done the "Basic Networking Troubleshooting #1" items.

  • Install the latest software package.  In fact, to match what we are running please use the latest beta version if there is one.

  • Update to the latest firmware.  Again, to match what we are running please use the latest beta version if there is one.

  • Make sure you are only running one software application at a time.  Don't run Kipling and LJLogM at the same time, for example.  Even close Kipling before running Ping.  T-Series devices have limited support for multiple sockets, and it is certainly possible to just disconnect from a connection in Kipling rather than closing Kipling, but to avoid confusion during troubleshooting only run one application at a time.

  • Similarly, make sure there are no other applications attempting to communicate with the device. Shut down any SCADA programs, OPC servers, or other programs—or ensure that they are not communicating with the IP address of the LabJack device. You may be able to restart or re-enable them later, but keep them turned off for the purposes of troubleshooting.

#2: Determine what is working and what is not

Use Ping to see if you have basic communication, as described in step 8 (Ethernet) or 14 (WiFi) on the Setup WiFi and Ethernet for the T7, T4, and T7-Pro app note. Do other types of opens (Native TCP, LJM Search, and LJM Specific) to see which work and which do not, as described in step 9 (Ethernet) or 15 (WiFi) on the Setup WiFi and Ethernet for the T7, T4, and T7-Pro app note. 

Ping does not work.

Suggests that no network communications are going through. Broadly, it should mean that the LabJack is not visible from your host computer network. Start with items #3, #11, and #12 below, then look at the rest of the items.

Ping works, but Specific Open does not work.

Suggests that the device is visible from your network, but may not be reachable over TCP. Usually this is due to an issue with the network and TCP configuration. Start with item #3 below and look at items #4 - #8 as needed.

Specific Open works, but Search Open does not.

Suggests that the connection is working, but the search technique used by LJM cannot find it. See item #9 below.

#3: The IP address is not valid on the subnet

Your LabJack device must be configured to be on a subnet that is accessible from your host computer. Open a command prompt window and type ipconfig to see a listing of the IP address and subnet mask for a particular PC. If the PC shows a subnet mask of 255.255.255.0, that means it can only talk to devices with the same first 3 bytes of the IP address. For example, if the IP address of the LabJack is 192.168.1.207, it will work on a network using the 192.168.1.* subnet (unless another device is already using the address). If the IP address of the LabJack device needs to be changed, the easiest way is via USB with the LJControlPanel (UE9) or Kipling (T-Series) application.

Tip:  It can be useful to send two things to us to help you troubleshoot:

  • Send the output of ipconfig from your computer.  Right-click on the little icon in the upper-left of the title bar of the Command Prompt window, and choose Edit Select All.  Then right-click again and choose Copy.  Now you can paste the info into an email.

  • Use LJControlPanel (UE9) or Kipling (T-Series) to connect over USB, go to a screen that shows the Ethernet settings of the device, and to <Alt-PrintScreen> to grab a screenshot and send that to us.

#4: Something else is using the same IP address

If another device is already using the IP configured for the LabJack, you should not be able to communicate with the LabJack.

Disconnect the LabJack device and ping the IP address in question to see if anything responds. For example, say that you want to configure your LabJack to use the IP 192.168.1.209. To ping this IP address, open a command prompt window and type ping 192.168.1.209.  If the LabJack is not connected there should be no response.

#5: Trying to use DHCP when there is no DHCP server available

T-series devices have DHCP enabled in the factory default state.  If DHCP is enabled on a device and you connect it to a network that does not have a DHCP server, that device will not get assigned a valid IP address and you will not be able to communicate with it.

This problem is common in a peer-to-peer network.  That is, with a direct Ethernet connection from the LabJack to the host.  The LabJack does not have a DHCP server, and most likely the host computer does not either, so you need to configure both the LabJack and the host to use valid (different) static IPs. See the Direct Connection via Ethernet App Note.

Most routers and some managed network switches can provide DHCP server functionality.

#6: TCP stack not initializing properly with a static IP

Some T7 firmware versions before 1.0217 had a problem such that the TCP stack did not start up properly when using a static IP.  It would work correctly when initially configured in Kipling, but then sometimes not work after a reboot.  If you are using a T7, make sure you are running firmware 1.0217 or higher.

#7: Cannot communicate between WiFi and Ethernet device/host

Check to see if the wireless access point (typically a router) has wireless isolation enabled. If wireless isolation is enabled, it will prevent an Ethernet computer from being able to detect or communicate with a WiFi device on the wireless network, because WiFi is isolated from Ethernet, and vice-versa.

#8: Firewall software on the host is blocking traffic or closing the connection

Try closing or disabling software related to firewalls or anti-virus.

For example, on Linux, if a Wireshark capture shows ICMP messages with "Destination unreachable (Host administratively prohibited)" related to port 502 or port 52362, try disabling the firewall as root:

# /etc/init.d/iptables save
# /etc/init.d/iptables stop

You can re-enable your firewall with:

# /etc/init.d/iptables start

For more about Linux firewalls, see this nixCraft post on how to disable the firewall in Linux.

#9: Perhaps the TCP connection is fine, but search does not work?

Kipling and LJControlPanel (via ListAll function) use a UDP broadcast search technique to attempt to find all T7, T4, or UE9 devices on the network, but with some networks this does not work and a direct TCP open must be done.

UD library (UE9)

  • In LJControlPanel go to Options→Settings and add specific IPs that LJCP will try to open directly.

  • At the UD API level search is used by ListAll, so instead use OpenLabJack with the specific IP address of the UE9 to see if a direct TCP open works.

  • In LJLogUD or LJStreamUD, you can force a direct TCP open (rather than a search) by editing the _open.cfg files as described on either page.

LJM library (T-Series)

  • As of version 1.15 (May 4th, 2017) the LJM library automatically stores network connection information to the auto IPs file to help open connections to LabJack devices.

  • IPs can be added manually to LJM Specific IP configuration to tell LJM particular IP addresses on which to try a direct open.

  • Both auto IPs and specific IPs affect not just Kipling but all ListAll and Open calls on that machine.

  • You can also do a direct TCP open in your software by calling one of the Open functions and passing a specific IP address (e.g. "192.168.1.207") for Identifier rather than passing "ANY".

  • In LJLogM or LJStreamM, you can force a direct TCP open (rather than a search) by editing the _open.cfg files as described on either page.

TCPOpenTesting

We have a Windows application called TCPOpenTesting available for download.

For LJM (T-Series) testing, try the following methods to open the device:

  1. native direct TCP (left side of application).

  2. LJM search open (middle of application with ANY/ANY/ANY).

  3. LJM specific open (middle of application with specific parameters such as T7/ETHERNET/192.168.1.207).

For UD (UE9) testing, try the following methods to open the device:

  1. native direct TCP (left side of application).

  2. UD specific open (right side of application with specific parameters such as LJ_dtUE9/LJ_ctETHERNET/192.168.1.209/FirstFound=FALSE).

Does your network have a router?

One instance where both direct TCP open and ping works but discovery by UDP broadcast fails is when the network does not have a router. Take, for instance, a network consisting of a managed switch, a T7, and a computer, where the switch is connected to the other two devices:

  1. When LJM on the computer tries to open the T7 by searching, it sends a UDP broadcast packet to the broadcast address.

  2. That packet goes to the managed switch, but a switch is not responsible for sending broadcasts to every IP on the network, so the packet gets dropped.

  3. If the managed switch was responsible for sending broadcast packets to each physically connected device, then the same broadcast packet would get sent to the IPs connected physically to the network switch — or else the switch would have to track which broadcast packets it had already sent. Also, the managed switch would require a list of all IPs on the network.

Essentially, you need to know what device on your network is acting as the router and make sure everything else on the network is using that device's IP address as the gateway address.

#10: Ethernet connection only shows up in Kipling when USB is also connected

This is usually a symptom of #9 above.

#11: The connection is not electrically valid

Sometimes, Ethernet connection issues could be due to a problem with the physical Ethernet connections.

With the UE9, check that the correct Ethernet cable connected.

The UE9 does not support Automatic MDI/MDI-X, so if the device on the other end of the cable also does not support Automatic MDI/MDI-X (a rare situation these days) then a crossover cable might be required.

Try a different Ethernet cable.

Ensure that the switch/hub/NIC supports 10Base-T for the UE9, whereas the T-Series devices support 10Base-T or 100Base-T.

Use the LEDs on the switch/hub/NIC to determine if you have an electrically valid connection.

An orange LED is often used to indicate a good 10Base-T connection, but consult the manual for the switch/hub/NIC to be sure. If there is any communication at all, such as ping, then you know the connection is electrically valid.

Make sure the LabJack device has power.

Do you see normal activity on the COMM and STATUS/CONTROL LEDs?

With the T7 or T4, look at the LEDs on the Ethernet connector for correct activity.

Check that the pins inside of the Ethernet jack are not bent downward or otherwise damaged.

Forcing a USB cable into the Ethernet jack can cause damage such as shown below:

Try wiggling the Ethernet cable near the Ethernet jack or applying upward pressure to see if that causes any LED activity.

#12: The LabJack device has been damaged and does not work at all

Use a USB connection to test basic functionality. Confirm proper LED behavior as described in device datasheet. Confirm installation and operation using the quickstart guide for the device.

Files

TCPOpenTesting.zip

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.