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

[Gilbert Ramirez <gram@xxxxxxxxxx>]

Here's the list of requirements I could muster for the Mother of All
Packet Capture Libraries. The main thrust is that Ethereal needs a packet
capture library tailored for general packet sniffing and protocol analysis,
not just TCP/IP testing.

Libpcap currently falls short in a few areas. Now that the tcpdump.org
folks are actively maintaining libpcap and tcpdump, we really should take
a look to see if our requirements can be met by a future libpcap. If not,
however, we should not hesitate to implement all of this in wiretap.

I never name "wiretap" in this requirements list, just in case libpcap
actually does work for us. But some of these requirements are slanted
towards a non-libpcap solution (e.g., #10, #11)

(I added #21 after checking my e-mail just now. I got lucky that I read
Guy's e-mail before sending this out. :)

Please comment and send any suggestions and modifications to ethereal-dev.

--gilbert

Packet Capture Library Requirements
-----------------------------------

0. The intent of this packet capture library is to provide a
cross-platform packet capture library designed for sniffer programs. It
should hide OS-dependent details about interfaces and packet capture
facilities from the calling program.

1. It should be easy to add new filterable objects to the library.
In fact, all filterable objects should be defined in the same manner
in which the library is meant to be extensible. (TCP filters should
not be "built-in", but defined in the same manner as someone would later
add SNA filters).

2. Capturing can occur on more than one network interface at a time,
which can be of different datalink types.

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.

4. Capture filters can be applied to the capture as a whole, or to each
interface being captured (in a multi-interface capture).

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, the program
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. In this way, a firewalled DNS
server, a change in A records, or missing /etc/ethers or /etc/ipxnets
file won't affect the name resolution of a saved trace file.

6. Compression will not be handled in the trace file format itself,
but by compressing the entire file with gzip and using libz to read it.

7. The packet-filter can be optimized for the host OS's capture facility.
Filterable fields and protocols should be defined in a generic enough way
(at compile time) to the library that it can produce code for BPF, NIT,
DLPI, etc.

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.

9. The grammar/parser for the filter language won't leak memory and will
be able to gracefully restart after a failed compilation.

10. Packet capturing will work on all OSes supported by libpcap.

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

12. The intent of the library is for local captures and not remote
captures.  RMON filters are not in the scope of this library, nor are
networked connections to remote capture agents.

13. However, a remote-capture client/server program *can* be made by
using the packet capture library for the actual packet capture on the
capture server (remote agent).

14. The library will provide for passing packet data directly to a
callback function, or saving it in a file. The file will be accessed
as a stream, not in random order, so that stdout may be used as the
output file.

15. Trace files will have version numbers for backwards compatibility.

16. Filters will only be used as capture files, not as read filters or
display filters. When using filters as capture filters, the library knows
what OS its running on and what peculiarities to expect (a full-length
token-ring header, raw IP for this datalink layer, etc.). However,
when using filters as display filters and read filters, not enough
information is known about the OS on which the packets were captured
to produce correct filters.  (See the workarounds needed in packet-tr.c
because of full-length headers found on Linux traces)

17. If a way to work around non-native-OS problem discussed in #16 is
found, then requirement #16 can be removed.

18. Any additions to the BPF psuedo-machine made by the workers at
tcpdump.org will be tracked and 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

20. The triggers in requirement 19 can be combined and used together.

21. Provide a function that returns a list of filterable interfaces,
to save the calling program from having to know about OS-specific details.