I would find it useful for there to be a specifications section in the ethereal
documentation, describing current limits of the program such as:
Number of bits of precision in byte counters for conversations, other statistics.
Maximum table size for endpoint addresses, conversations, etc.
Recommendations of minimum hardware versus speed of network to be
captured.
Also, does ethereal support error packet reporting & capture? It's my
understanding that few protocol analyzers under $1000 do, but sometimes
this is the most interesting part of the traffic, and requires the NIC driver
support the capability. Many analyzers omit from a capture, packets that
have bad headers, are too short, overlong, etc. or the driver screens them
out instead of passing them to the analyzer. These can be created by
having a fast network bridged to a slow one creating collisions, or
malfunctioning gear on the network.
http://www.etherpeek.com/elements/etherpeek/EtherPeek_SE_TechSpecs.pdf
Can ethereal handle more than one capture at a time performed by a
single system, whether with one NIC or more than one? (Refer to
Observer or Etherpeek online documentation describing this capability.)
http://www.etherpeek.com/elements/technical_briefs/TB002_Multi_NIC_Brief.pdf
Some commercial analyzers include an option called a remote agent.
This is software that is installed on another system that communicates
with the main software, so that statistics & captures can be collected
from multiple places in a network. It also somewhat distributes the
CPU load.
Another feature I find useful is the ability to start and/or stop captures
based on specific trigger conditions, such as traffic level or error rate
above a threshold, or a specific source address is seen or packet
data pattern is seen, or a specific alarm condition occurs (which could
be error rate, traffic level, duplicated IP# seen with different mac#'s,
traffic with a particular protocol & destination port #, etc.). Precapture
before a trigger condition would be great; I've not seen that offered,
but often the question arises when an alarm is seen, what occurred
just before the alarm or trigger?
Thanks,
Ken
