Ethereal-dev: Re: [Ethereal-dev] Interesting new filetypes to possibly handle...

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 14 Oct 2003 16:30:56 -0700

On Oct 14, 2003, at 4:12 PM, Joe Patterson wrote:

There are two filetypes (sort of...) that I was wondering how difficult it
might be to get ethereal to handle (and what good it might do...)

One, which is perhaps the most novel, is handling packet dumps from cisco
routers.  On a Cisco router, if you issue the command "debug ip packet
{access-list #} dump", it will start dumping the hex representation of the full packets which match the access-list #. If you have your syslog set to debug level, it will actually log these to a syslog server. It seems that
it shouldn't be *terribly* difficult to write a parser that reads in a
syslog file, gets the time/date stamps from each syslog message, and the
data from the hexdump, and parses it into something that can be easily
displayed in ethereal.  Anyone have any thoughts?

If one wanted to implement that, one might want to look at some of the other text-file dump readers in the wiretap directory.

The second, which I'm wondering if it's usefull at all, is a parser for
snort's unified output file format. this format is *almost* identical to libpcap, but has extra data added to each frame (stuff like which snort rule caused this particular packet to get tagged). Now, it's probably fairly trivial to write something to read in these files and display the standard
information.

Assuming they didn't do somethng stooopid such as using a standard libpcap magic number, or not having any magic number at all, it should be fairly easy to add to the existing wiretap/libpcap.c the ability to read those files.

  It's also fairly unecessary, as there are tools to "extract" a
libpcap-formatted file from a snort unified output file. However, if there were a way to get ethereal to actually do something usefull with the extra data (i.e., parse it out and show it in the protocol tree with the other
frame meta-information such as time, time_delta, time_relative, number,
pkt_len and cap_len),

That could probably be done without too much pain, although, without a description of the file format, I don't know what I'd recommend as the way to do it.