Troubleshooting networks

Network problems may be physical, electrical or software-related. For that reason, troubleshooting networks can be challenging. Fortunately, computers come with hardware and software that can help you isolate and resolve most problems.

ZoneAlarm Pro lets users enable specific ports to pass through the firewall using the “Custom” settings of the firewall.

If your computer is unable to communicate on the network, the first thing to check is the link light. The link light can be found on the network interface card (NIC) or next to the RJ-45 connector on a laptop. It usually indicates two things — first, that the network card drivers have been installed and the computer has detected the card and, second, that an electrical connection exists between the card and another network component such as a hub or switch. If the light is out things definitely will NOT work. If the light is on, then you may or may not be able to access the network, but you do have a physical and electrical connection between the computer and a network device.

If the light is out, check the physical connection to be sure the RJ-45 connector is seated properly. Move the connector at the far end to a different port on the switch. Run a new cable between the computer and the switch. But before you do that, try a different computer — or, better yet, a laptop — to see if the computer itself has a problem. If the link light comes on with a different computer using the same wire, then it is time to check the drivers to see if they are communicating with the NIC. Many NIC cards come with test utilities that will verify that the drivers are working and that the card is installed correctly. You may want to uninstall the drivers and then re-install them. Follow your NIC card manufacturer's instructions to do this. (Remember that updated drivers for your NIC may be available for download over the Web.)

I would like to explore another problem that has been the cause of a lot of frustration for many engineers running Windows. The problem is this: Sometimes a client computer cannot locate a server. You know that the server is up and running, and perhaps you have other computers on the network that have already connected to the server.

Normally, you would double click “My Network Places” and choose “Computers Near Me.” You would then see the server you wish to attach to, double click its icon and enter a username and password. But frequently, the computer you want to attach to does not appear in “My Network Places,” and clicking “Computers Near Me” and “Entire Network” fails to reveal it. Many times it is possible for you to ping the server successfully, but you still cannot access it in Windows. If you are having this problem, here are some things you can try.

First, try pinging the server. Go to “Start” and then “Run.” Type “Command” in the box and select “OK.” Once the DOS window opens, at the command prompt type “ping” and the IP address of the server you want to ping. You should see a series of messages with a “Time To Live” (TTL) indicating that the ping was successful. (It used to be that, if the server was up, you could ping it. And in most cases with internal servers, this is still the case. But be aware that many servers connected to the Internet now have been configured to not respond to ping requests because this has been used in Denial of Service attacks in the past.) In any case, if you can ping the server, this is one more indication that a good network connection exists between you and the server, and that it is up and running. If you are unable to ping the server, first check to see if the server is set to respond to ping requests. If you can ping the server from other computers but not the one with the difficulty, you must correct this problem before you can connect.

Your computer must belong to the same workgroup as the server. If not, you will not be able to connect to it. Usually the workgroup name will be WORKGROUP. To check your computers' workgroup, right-click on “My Computer,” and select “Properties” and then “Network Identification.” Still unable to see the server? Check with your network administrator to be sure there is a Windows Name Server (WINS) running on the network. Oops — you are the network administrator? Well, you can either configure the server you are trying to attach to as a WINS, or you can try attaching to the server without using WINS.

Sometimes you can find a server by searching for it even if it does not show up under “Computers Near Me.” Go to “My Network Places” and select Search. Enter the server name preceded by two backslashes — Example: \\dill_pickle. If you still cannot find the server, and the target computer has a shared drive (for example, D:\), there is one last trick that may allow you to attach to the shared drive directly. Select “Start” and then “Run.” Enter the computer name followed by the shared drive's name — Example: \\dill_pickle\c:. Choose “Ok.”

This “invisible server” problem can be particularly vexing. If you have other suggestions that have worked in the past, please email them to me at so I can share them with others.

Another problem that can be particularly troublesome for broadcasters is getting specialized software to operate correctly with firewalls. Broadcasters may need to run tight security on their connections to the Internet, but they may also need to enable special services to support their users. You should not start making changes to your firewall setup without having a backup plan in mind in case it takes you a while to get the firewall back up and running.

Most firewalls perform Network Address Translation (NAT) so that addresses of computers inside the network are hidden from the Internet. Firewalls may also perform Port Address Translation (PAT) so that a computer on the local network (a Web server for example) can be seen from the Internet. With the exception of a few well-known ports (for example, Web browsers, FTP and Telnet), most firewalls block attempts to communicate with a computer using unknown ports. However, a broadcaster may be using a special audio application, high-end video conferencing software or some other specialized software that requires other ports to be enabled through the firewall.

If the firewall is not properly configured for these specialized applications, the user may see some sort of communications error message, or a timeout error because the application is unable to establish communications with the desired port on the computer at the other end. Fortunately, the fix for this is fairly straightforward. First, you will need to read the documentation for your application to find out what ports and protocols it uses. Usually the documentation will specify the port and whether the application is using UDP or TCP. Sometimes you will find this information on a support section of the manufacturer's Web site under “Firewalls.”

As an example, an application I use requires that ports 5118 and 5119 be open for UDP and that port 5200 be open for TCP. Next, you will need to do some more research on your firewall. Almost all firewalls have a port configuration area that allows you to define which ports may pass through the firewall. Some firewall applications try to make things easier by specifying applications (such as WWW or FTP) along with the port numbers. But in my example above, because this was a voice-over-IP application that was not very common, I needed to enter the information directly.

Once you have learned how to set up this area of your firewall, just enter the information into your firewall and test the application to see if it works. One final note — on some firewalls, ports can only be opened for a specific address on the local network. You have to tell the firewall software the IP address of the computer inside the firewall that needs to have access to the specific port. The firewall does not allow that port to pass through the firewall for every computer on the network. If your firewall works in this way, you cannot use DHCP on the inside of your firewall, because the IP address of the target computer will change each time the lease with the DHCP server expires. (Apologies if this gets a little complex, but I spent sometime figuring it out and wanted to pass the information along.)

As computers and networks become more important to broadcast operations, troubleshooting these technologies becomes more critical. It is important for broadcasters to obtain training and experience in maintaining networks as part of their overall professional expertise.

Brad Gilmer is president of Gilmer & Associates, executive director of the AAF Association and executive director of the Video Services Forum.

Send questions and comments

Home | Back to the top | Write us