Ethereal-dev: [Ethereal-dev] Re: [tcpdump-workers] New capture file format ideas?
I'm not sure if Jason Thorpe (NetBSD) has caught up with this list but
in discussions with him, he's raised the prospect of using the tcpdump
save file as the format to be used for generating log records from the
kernel when doing packet filtering. The ideas below are my own on this
subject but I would hope some of them coincide with Jason's. If you
were using IP Filter, the idea is you could do this:
tcpdump -r /dev/ipl
to decode your log messages (well sort of :).
If this were to be the case, then there is one of two ways to go here,
I think. The first is to try and specify a number of extra fields which
we think will be "the limit" on what's needed and the second is to
support the insertion of extra meta-data between the tcpdump header
record and the actual packet. Two extra fields would be required for
the second method, one to say "what type" of meta data is following and
the second would be "how much" extra meta data is there.
To give you an idea of what extra fields would be required for ipfilter
logging if it used tcpdump are:
- repitition count (for identical packets logged sequentially)
- interface name and number
- syslog facility and priority
- rule number
- group number
- flags associated with the packet (pass/block, etc)
- global logging flags set
...then for NAT/state log entries it doesn't log the IP header(s) but
all the addresses/ports involved as well as byte/packet counts for the
session. To me it seems wrong to be putting so much extra information
into the tcpdump log file, explicitly especially as it constrains the
applications using it. Then again, I'm not so sure tcpdump needs more
magic numbers either...
Comments ?
Darren
