How to quickly identify error conditions with Ethereal.
(Last modified: 15Jul2003)
This document (10084809) is provided subject to the disclaimer at the end of this document.
goal
How to quickly identify error conditions with Ethereal.
fact
Ethereal 0.9.13
fix
The quickest way to identify problem areas in a packet trace is to configure color filters to highlight problems. I typically create color filters to mark errors in red so that I can quickly scan through a trace and identify potential problems.
For detailed information on how to create a color filter please refer to How to configure colors in Ethereal
Below is an example of what I have configured to be flagged with Red in Ethereal.
TCP related errors
tcp.analysis.retransmission
tcp.analysis.lost_segment
For the tcp analysis to work then you must enable the sequence number analysis in Ethereal. First select the menu option Edit, and then click on Preferences.
When the preferences dialog opens, click on the protocols section to expand it, and then scroll down to TCP. One of the TCP preferences is Analyze TCP sequence numbers. Enable this option to allow Ethereal to check for missing segments, retransmissions, etc...
So for our color filter we want to set the color to red if there is either a retransmission or a lost segment. If either of these conditions exist then Ethereal will set a flag within the packet decode to indicate the condition. All we need to do is to test for the existence of the flag to determine if the packet contains one of these conditions. Our filter string would look like this....
tcp.analysis.retransmission || tcp.analysis.lost_segment
Or we could also write this as...
tcp.analysis.retransmission or tcp.analysis.lost_segment
If either of the flags that are defined in our color filter are true, then the packet will be colored in red.
Also within the decode window we see new information has been added to the TCP header with the analysis information.
NCP related errors
NCP errors are very simple. The NCP protocol establishes a return value. This value indicates 0 if successful or some other value to represent an error.
ncp.completion_code != 0
In this color filter we are just wanting to colorize any packets that are returned with a non-zero value.
Note: The NCP server only returns a numerical value for the error. The actual string that is displayed is included in Ethereal. Many other analyzers may not be able to give you this type of detail so you will have to look up the error code. It is important to know that errors being returned by the server are proceeded with 0x89. So in this example the real error code being returned by the server in packet 50 is really 0x89ff. Novell documentation gives at least 10 different descriptions for this error code. Without Ethereal already displaying the correct error message, then you would have to look up the error code and try to determine which error description really matches this NCP request.
Another condition that we should trap for under NCP is the Server Busy packet. The purpose of this packet is to inform the workstation that the server is processing its request. For example, a workstation makes a request for information from the server, the server does not reply because it must contact another network resource to complete the request. The workstation times out on the request and assumes that the packet was dropped since the server never replied. So the workstation issues the same request again. When the server receives this duplicate request it responds back to the workstation with a Server Busy packet. The workstation then will wait for a proper response from the server since it now knows that the server got the request. The Server Busy packet is a special NCP type. To understand how we can trap for this condition we must understand the different NCP types.
NCP types:
0x1111 = ALLOCATE SLOT
0x2222 = SERVICE REQUEST
0x3333 = SERVICE REPLY
0x3e3e = WATCHDOG
0x5555 = DEALLOCATE SLOT
0x7777 = BURST MODE XFER
0x9999 = SERVER BUSY
0xbbbb = DIRECTED BROADCAST
0x4c69 = LIP ECHO
If we look at the decode of a Server Busy packet we see that the element name for the NCP type is ncp.type.
So to mark all the NCP packets that contain a server busy NCP type we just need to create our color filter for ncp.type==0x9999.
Now I want to identify all NDS return values that contain errors. NDS utilizes the NCP 104 (NDS Fragment packet). Within this NCP packet, NDS will identify a verb that the packet contains information for. NDS verbs are how NDS communicates on the network. All NDS reply packets will show the following information.
1. The NCP completion code - This is the normal NCP return value as noted above. A value of 0 means the NCP processed without error. This does not mean that NDS completed successfully.
2. The NCP connection state - 0 means connected, 1 means not connected.
3. The NDS fragment size - The size of the reply.
4. The NDS fragment handle - If this value is 0xffffffff then the data is not fragmented over multiple packets. Otherwise expect multiple fragments to complete the data structure.
5. The NDS completion code - This is the value to indicate if NDS had an error or not. A value of 0 indicates no error. But any other value is an error. This only applies to non-fragmented packets.
Following the NDS completion code will be the NDS verb data. To trap for NDS errors we need to find all NCP packets that contain a non-zero NDS completion code.
We see in the picture below that the element name for the NDS Completion Code is ncp.ndsreplyerror.
So we compose our filter as ncp.ndsreplyerror != 0x00000000
We could have written the same filter as ncp.ndsreplyerror not eq 0. Note that the "!", "bang", or "Exclamation point" means not.
NDPS related errors:
Ok, now lets look at another protocol. In this example we want to trap for all NDPS errors. The NDPS protocol returns errors in several different places. Thus we have to trap several different elements to get everything. We could create separate filters for each element or we can create one filter to trap all of the elements. NDPS utilizes RPC or Remote Procedure Calls as it's transport. The actual RPC protocol can return an error. The NDPS protocol can return an error. And finally the actual NDPS component can return an error. We must trap for each of these so that we don't miss any errors.
The first thing we want to trap is the RPC Accept Status. This is the status returned by the RPC protocol. The element name is ndps.rpc_acc_stat. Any non-zero value will be an RPC error.
We can write our filter as ndps.rpc_acc_stat != 0
Let's check for the NDPS protocol return status. We see that the element name is ndps.error_val. Again a non-zero value would indicate an error.
So we write our filter as ndps.error_val != 0
Finally let's trap for the last error condition in an NDPS packet. This would be the Return Code. Any non-zero value indicates an error so we compose the filter:
ndps.ret_code != 0
As stated above we could create individual filters for each of these conditions. But, it would be much easier to create one filter with the name of NDPS errors and then give it the filter string of:
ndps.error_val != 0 || ndps.rpc_acc_stat != 0 || ndps.ret_code != 0
Note that the "||" is two pipe symbols and means the same as the word "or". So in our expression we mean condition 1 or condition 2 or condition 3.
Conclusion:
Trapping for errors in Ethereal is an easy process if you know how to configure color filters. With a little practice filters will become very easy to use. You will also find that flagging errors with color filters will make the packet trace analysis process much easier and quicker. The hard part in this whole process is identifying the exact error conditions to trap for. Each protocol will contain its own return values and error code structures. You will need to identify the items you want to track in the protocol you are troubleshooting. As you read traces make notes of errors that you encounter and compose a new color filter to trap for these conditions. This way you can quickly find the same condition without having to go through the same process again and again.
.
note
Note: Ethereal is a free open source product. Novell does not provide support for this product. The purpose of this solution is to provide Novell employees and it's customers with information regarding the use of this free tool. To download, report issues, or to request for any enhancements, please consult the Ethereal website at
document
| Document Title: | How to quickly identify error conditions with Ethereal. |
| Document ID: | 10084809 |
| Solution ID: | NOVL90853 |
| Creation Date: | 07Jul2003 |
| Modified Date: | 15Jul2003 |
| Novell Product Class: | Netware Client |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.