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.