Ethereal-dev: Re: [Ethereal-dev] ethereal 1.0 features?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 13 Jul 2001 12:04:22 -0700 (PDT)
> [Charset iso-8859-15 unsupported, skipping...]

Sigh.  EMU now obliges me to upgrade my mail reader (time to start using
Mutt at work, as I do at home, perhaps...). :-)

> 11. Add capture from stdin to tethereal (maybe this should go into
>     wiretap anyway.

The only hard part is getting rid of the seeks; doing some of our own
buffering should let us eliminate the seeks within those capture file
readers obliged to do various gross heuristics (e.g. libpcap).  Some
capture file formats can't be read sequentially (e.g., Network Monitor),
but Wiretap would just return "sorry, no way" on

	1) attempts to open those file formats from a pipe;

	2) attempts to open a pipe if random access is required (Wiretap
	   get passed a flag specifying whether random access is
	   required or not).

That obviously won't work well for programs such as Ethereal that have
to do random access, but for sequential-access-only programs such as
Tethereal, it should work.

> 12. add capture from RMON probes (IIRC Richard wanted to give it a try)
>     to wiretap

I.e., add a "wtap_open_live()", which would include plugins for libpcap,
SNMP/RMON, etc.?

> 14. A "compiler" to translate Ethereal (Display) syntax into Tcpdump
>     (capture) syntax  so there is only on syntax left.

Actually, we'd probably still want to allow libpcap-syntax filters, as
well as a subset of Ethereal syntax.

>     It might just tell you which options were ignored because the
>     capture engine doesn't support them

"Doesn't support" as in "can't be compiled into BPF machine code", or
"doesn't support" as in "not all versions of the libpcap compiler
support everything we'd want to do"?  A bunch of stuff we might want to
use in the libpcap language are just syntactic sugar around access to
raw link-layer/IP/etc. header data; I was thinking of leaving the
syntactic sugar off and generating stuff, whenever possible, that any
libpcap compiler should handle.

> 15. Add some sort of metadata frames to captures including name resolving
>     info and maybe comments about the capture itself

That's been mentioned in the tcpdump-workers discussion of Libpcap
Format - The Next Generation.