On Fri, Apr 04, 2003 at 04:25:32PM -0800, Ben Carter wrote: > If this question has already been answered I apologize for my inability > to find it in the mailing list archives or the FAQ.. > > Is it possible to display the IP identification number in the main > display?
There is no mechanism for doing that, although there is a tap mechanism to allow arbitrary fields to be shown in the summary output in Tethereal: hostname$ man tethereal ... -z Get Tethereal to collect various types of statistics and display the result after finishing reading the capture file. Currently implemented statistics are: ... -z proto,colinfo,filter,field Append all field values for the packet to the COL_INFO information line. This feature can be used to append arbitrary fields to the COL_INFO line in addition to the normal content of the COL_INFO line. field is the display-filter name of a field which value should be placed on the COL_INFO line. filter is a filter string that controls for which packets the field value will be presented on COL_INFO line. field will only be presented on the COL_INFO line for the packets which match filter. NOTE: In order for tethereal to be able to extract the field value from the packet, field MUST be part of the filter string. If not, tethereal will not be able to extract its value. For a simple example to add the "nfs.fh.hash" field to COL_INFO for all packets containing the "nfs.fh.hash" field, use -z proto,colinfo,nfs.fh.hash,nfs.fh.hash To put "nfs.fh.hash" on COL_INFO but only for packets coming from host 1.2.3.4 use : -z "proto,colinfo,nfs.fh.hash && ip.src==1.2.3.4,nfs.fh.hash" This option can be used multiple times on the command line. > This will be very helpful when examining UDP video streams for > missing packets (these packet captures can be 120,000+ packets). > Better yet, is there any way ethereal can raise some sort of flag when UDP > packets arrive out of order or are missing? Given that there is no notion of "out of order" or "missing" UDP packets - UDP has no sequence number to allow an order to be determined or to indicate that there are gaps in traffic - no, there is no way it, or any other program that deals with captured network traffic, could ever do so for arbitrary UDP packets. It might be possible for dissectors for particular protocols running *on top of* UDP to do so if *those* protocols had some form of sequence number. However, no such dissector has, as far as I know, any feature such as that.