Guidelines to Take a Packet Trace.

Communication Problems.
Unable to login
Guidelines to Take a Packet Trace.

Occasionally Novell Technical Support Engineers will request that you get a packet trace of a problem occurring to help troubleshoot an issue. If you do not have software to take a trace with, there are two different products you can use for free: LANalyzer and Wireshark. Wireshark has the advantage that it works on about any platform, while LANalyzer works only on Windows 95/98.

For more information about Wireshark see How to use Wireshark to capture a packet trace.

For more information about LANalyzer see How to take a packet trace with LANalyzer for Windows

Novell Technical Support can also accept traces taken with SnifferPro, NetMon, tcpdump/WinDump and most other commonly used formats.

Please review the following potential problems prior to attempting the packet trace.

Packet traces contain only broadcast traffic

If the destination address is always displayed as FFFFFFFF (IPX) or always ends in .255 (IP) then all you have captured is broadcast packets. This is a useless trace.

If you are running the capture tool on the target machine, then do not enter a filter at all. If you are tracing another machine (to start the trace while the target is off and capture the bootup process), you will need to mirror the ports on the switch, or plug the workstations into a dumb hub and plug the hub into the switch. If the hub has intelligence to prevent the workstations from seeing each other's packets, then we will not be able to get a good trace.

The Wireshark website has a good FAQ on this subject. Please refer to http://www.wireshark.org/faq.html#q7.1

Capturing in promiscuous mode

Promiscuous mode is the ability of the board and driver to capture packets whose destination address is set to any node on the network, not just its own. This is an absolute requirement for use with analyzer products, for both Ethernet and token ring. Your adapter should support promiscuous mode otherwise you will only be able to capture packets that are either originated or are destined for the local workstation. This is usually no longer a problem with newer network adapters. But you should still be aware in the case where you are using older hardware. If you are uncertain as to whether your adapter supports this mode then please consult the vendors documentation. Another method to validate this is to perform a capture to see if it displays any other traffic other then the local and broadcast traffic. If you are only concerned with tracing the local workstation and no other traffic then this should not be an issue.

Packet size slicing

Most analyzers have the ability to set the maximum packet size to capture. It is very important that you capture the complete packet and not limit the size. Some analyzers will default to a maximum size for packet slicing. Please consult the documentation on your tool and ensure that full packet captures are performed.

Capture file size

Analyzer software capture packet data to a temporary file. The size and configuration of this file is important in the ability to capture a complete trace. Some tools will wrap when the file size is exceeded so that the first part of the trace is overwritten. This makes packet trace analysis by Novell extremely difficult since parts of the trace are missing. Please consult the documentation on your tool to ensure that this does not occur. Most tools allow you to configure the size of the capture file as well as how to handle when the file becomes full. This might include rolling the data to a new file, or just stopping the trace.

These are potential questions the Novell support engineer may have about the packet traces:

What is the problem? (when did it start? steps to reproduce? any other pertinent information)

What steps were traced?

Give names of the servers & files being accessed.

If the workstation running the packet analyzer and the workstation being traced are close to each other, you can make a note of the packet numbers throughout the process. For example: Packets 1-30 are boot. Packets 31-500 are login. Packets 501 to 1,000 is my application loading. Packet 1,001 to 1,500 is me saving my file. The error occurred at approximately packet 1,480. Many times it is easier for Novell to analyze several smaller traces of each activity then it is one large trace of everything. Consider starting the trace, performing one activity, stopping the trace, and save it with a name that is descriptive of that activity. Then start the trace again, and perform the next activity. This allows the person performing the analysis to more quickly jump to the exact part of the trace instead of having to weed through thousands of packets.

Give the MAC addresses of hardware involved? (Workstation, servers, printers ...)

What is the workstation configuration?
Is it NT or Win9x?
What version of the client is running?

If it works with one version of the client (or a particular server patch), then get a trace of it working, and a trace of it not working.

Are there any client patches loaded?

What version of NetWare (and other relevant products i.e. ZEN or NDPS) are running on the server?

What patches have been applied?

What is the configuration of the network? Are there routers involved? If so, what kind of routers?

Please note. The more information you can provide the quicker it will be to get a analysis of your packet trace. For example other devices in your environment, domains, mainframes, Unix, Web, etc...

.

A common procedure for taking a trace would be to try to get two traces, one of a workstation that works and one of a workstation failing. When doing this, it is important that the exact same steps are followed in each trace so they can be accurately compared. The following steps are useful in this case:

1. Follow the steps 1-5 above to set up the trace of a failing workstation.

2. Start the trace, then turn on the target workstation. Once you have completed logging in and the operating system has finished loading, then write down the packet number showing in the LANalyzer dashboard (or other trace utility).

3. As you recreate the error, between each step pause and make a note of the packet number once that step has completed. For instance, load the application -write down packet number, open a file -write down packet number etc. etc.

4. Once the issue that you are trying to capture has been completed, you can stop the trace, save it and send the trace in to Novell for analysis. Then repeat the EXACT SAME steps for the workstation that works. Include a note indicating the steps that were followed and the packet number at the end of each step for each trace.

Formerly known as TID# 10011012