Wireshark · Ethereal-dev: Re: [ethereal-dev] Packet capture library requirements

[Guy Harris <gharris@xxxxxxxxxxxx>]

> 3. Capture filters can be created in a syntax that is appropriately
> powerful yet protocol-independent. That is, I don't like the TCP-centric
> syntax of libpcap, but the generic "protocol.field" syntax of Ethereal's
> display filters.

It might also be useful to separate the text parser for that syntax from
the code generator, so that, for example, one could construct expression
trees directly in a GUI filter constructor, and hand them directly to
the library.

However, it might also be useful to take the expression constructed with
a GUI and translate it to a textual expression, so that a GUI used to
construct filter expressions would offer both some graphical
representation *and* a textual representation of the filter expression,
allowing you to edit either one; if so, then it might not be necessary
to support handing something like an expression tree to the library.

> 5. Name resolution records can be stored in the trace file. While it won't
> be the job of the packet capture library to resolve names,

Actually, if the packet capture library includes a parser for filter
expressions, it might have to do name resolving in order to, say,
translate

	ip.addr == hello.sailor.com

into code to compare the IP source or destination address against any of
the IP addresses for "hello.sailor.com".

(Yes, there is a "sailor.com".  No, there doesn't appear to be a
"hello.sailor.com". :-))

"libpcap" includes a name resolver, which it uses for that purpose. 
However, it's not documented in the man page, or mentioned in "pcap.h",
so it's presumably not considered to be exported from "libpcap", and
"tcpdump" has its own name resolver, so it still needn't be the job of
the packet capture library to provide to its clients the ability to
resolve names.

> against which the library is linked might resolve names for any protocol
> (IP, IPX, ...)  and store these names inside the trace file itself,
> so that names will travel with the data.

Note that, for what it's worth, neither Microsoft Network Monitor nor
"snoop" store name/address pairs in the capture file itself; instead,
they have the ability to read a separate file containing name/address
pairs, and Network Monitor, at least, can write out its table of
name/address pairs to a file (I forget whether "snoop" can do that, or
whether it expects you to, say, cut-and-paste lines from the
"/etc/hosts" file, or from "ypmatch"/"ypcat" outut).

> 8. If a user requests a capture filter whose syntax is beyond the scope
> of the OS's packet capture facility, a BPF filter will be created and
> a user-land BPF implementation will be used to filter packets.

It might be nice, if possible, to construct a native OS filter to
discard out all packets that would be discard out by the full capture
filter and that can be recognized using only the capability of the OS's
packet capture facility, so that the BPF filter needn't see *all*
packets.  I think it might be possible to do this.

However, I don't think that need be a requirement for the first
implementation; it can probably be added transparently in later
releases.

> 11. A port of tcpdump using the packet capture library will be made.

"Port" in the sense of modifying "tcpdump" to use our library, or in the
sense that the library should offer a "pcap"-compatible API as well as
the native API?

Some others:

	The library should support captures on all network types
	supported for raw packet access by the OSes the library supports
	(e.g., if an OS lets you do captures on X.25, or ATM, or ISDN,
	or..., we should support that, as well as supporting the usual
	LAN networks).  (Or, at least, it should be possible to *add*
	that capability reasonably easily, and without API changes.)

	It should, at least on those OSes that allow "select()" on file
	descriptors for raw packet access, to get a file descriptor on
	which an application can do a "select()", with the "select()"
	blocking until a captured packet can be read from the capture
	stream corresponding to that file descriptor.  (This could be
	used to capture from multiple interfaces, and could also allow
	the same main loop to handle user input to a capture program and
	the arrival of captured packets.)

	("select()" could perhaps be replaced by "the selection
	mechanism used by X libraries to wait for input", so that the
	toolkit's "add a file descriptor to the list waited for in the
	toolkit's main loop" function can be used.)

> 19. The packet capture facility will have these stop triggers:
> 	A. A "seen" packet count is reached.
> 	B. A "captured" packet count is reached.
> 	C. A time limit is reached.
> 	D. A function is called (a user stops the trace)
> 	E. A fixed-length disk buffer is full

We might also want to add

	F. A packet matching a given capture filter is seen

with, perhaps the ability to stop some number of packets *after* that; I
think Sniffers and Network Monitor can do that.  We might also want a
*start* trigger - currently, that one would have to be done in userland,
and allowing the capture to start some number of packets *before* the
trigger packet, which I think some sniffers can do, means saving that
number of packets in a FIFO, so you would still have to copy packets
that wouldn't be saved.