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, but I keep getting lost and not getting anywhere.
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 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.
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?
-Peter K. Lee