Ethereal-dev: Re: [Ethereal-dev] internals of wtap_dump() command...
On Thu, Sep 20, 2001 at 02:44:53AM -0400, Peter K. Lee wrote:
> For the life of me I can't figure out *exactly what* wtap_dump() command
> does. All I know is, given a filehandle (of sorts), the wtap header
> info (which is generated), and the msgbuffer, along with the error code
> controller(?), it does some "magic" on it, producing the capture file
> which is 'generally' saved on disk.
>
> I tried to search through the source code(s), to try to find out how it
> achieves this,
It achieves this by calling the "write" routine for the particular type
of capture file you're writing (libpcap, Microsoft Network Monitor,
Sniffer, etc.).
Those routines - e.g., "libpcap_dump()", for libpcap format - achieve
this by whatever means is appropriate for the file format in question.
"libpcap_dump()", for example, constructs, from the wtap header, a
structure containing the record header - one of the four count 'em four
different record headers used by various flavors of libpcap - and writes
it to the standard I/O output stream, and then writes out the packet
data.
The "error code controller" is just a pointer to a variable into which
the "write" routine will store an error code, if the call fails. The
routine returns TRUE if it succeeds and FALSE if it fails.
> What I'd *really* like to know is how to take the filled msgbuffer
> (unsigned char array) freshly read from the socket, and without
> "calling" wtap_dump() with the msgbuffer and generating a capture file,
> be able to do analysis on the msgbuffer itself.
I.e., you want to write a program that uses Wiretap to read a capture
file, and processes the packets without saving them to a file, just as
"tethereal -r" does if it's not given a "-w" flag?
If so, then...
> I didn't think it was
> going to be this difficult, but I'm having difficulty connecting the
> msgbuffer to the output generated by wtap_dump(). I just can't see the
> connection. If I start to do a bit-by-bit analysis on the output
> generated by wtap_dump(), I start to see where the "fields" of the
> protocol is, and get an idea of what some of those values are, but once
> I start trying to do the same for the raw output from the msgbuffer
> itself, I just can't figure out where anything is.
...you should completely ignore "wtap_dump()", as you're not going to be
using it.
There are two ways of doing this.
Both of them involve calling "wtap_open_offline()", and saving the "wth *"
it returns; that's a "handle" to use in subsequent Wiretap calls.
The first of them involves calling "wtap_loop()", and having your
program supply a callback routine which "wtap_loop()" calls for each
packet it reads.
That callback routine is called with four arguments:
a "u_char *" which is the same value that was supplied as the
fourth argument to "wtap_loop()" - it's used as a way for the
caller of "wtap_loop()" to pass information to the callback, and
should really be thought of as an untyped pointer, so the
callback would cast it to point to whatever data structure the
caller of "wtap_loop()" passed in;
a "const struct wtap_pkthdr *" that points to the Wiretap
header, giving the time stamp of the packet, the number of bytes
of packet data that were captured, the number of bytes of packet
data that were in the packet (not all of which were necessarily
captured, so it may be greater than the number of bytes that
were captured), and the link-layer type of the packet;
an "int" that's the offset, in the file, to be used later to
re-read the packet's data if you're doing random access (as
Ethereal does);
a "union wtap_pseudo_header *" that supplies some information
that's sort of an "extension" to the raw packet data;
a "const u_char *" that points to the raw packet data.
> Okay, I just figured out somewhat what the problem was... What is all
> the junk in front of the relevant header where the IEEE 802.11 frame
> starts?
The "junk" where? In the capture file? If so, it's the header that the
particular capture file format puts in front of each packet in a capture
file, giving information such as the time stamp, packet captured length,
and packet length.
