wmeng wrote:
Jnetstream can read the capture file but at the very end of it contain the
"unknown" data(frame table) that can't deocde by jnetstream and it output
as having invalid data in the stream. Below is my capture file that open
in ultraedit
.. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. ..
10 00 09 3A 80 00 01 51 80 80 00 00 00
/\
As i know frametableoffset in netmon.c represent how many data (total data
in byte) in the capture file. Mean while frametablelength represent how
many data or "frame table" (in byte)in a capture file and it increase
4byte for each packet in that file. Jnetstream suppose decode until /\ and
the 80 00 00 00 is the "frame table or frametablelength". unfortunely
jnetstream decode 80 00 00 00 as invalid data.
Then it needs to be fixed not to do so; otherwise, you won't be able to
read files in Network Monitor format.
A Network Monitor file begins with a 4-byte "magic number" (either "R",
"T", "S", "S" for 1.x files or "G", "M", "B", "U" for 2.x files). After
that comes the structure described in "struct netmon_hdr" in
"wiretap/netmon.c". All multi-byte integral values in that structure
are little-endian.
"frametableoffset" is the byte offset, relative to the beginning of the
file, of the frame table. "frametablelength" is the length of the frame
table, in bytes.
The number of packets in the file is the number of 4-byte entries in the
frame table (i.e., "frametablelength" divided by 4). Code that
sequentially reads a Network Monitor capture file *MUST NOT* try to read
more frames than that; if it doesn't stop after reading that many
frames, it'll start reading the frame table as if it were frames, and
will probably get an error. The way not to get that error is not to
read more frames than the header says are in the file.
The Nth frame in the file starts at an offset, relative to the beginning
of the file, equal to the Nth entry in the frame table. All the offsets
in the frame table are little-endian. The N+1st frame is *NOT*
necessarily immediately after the Nth frame, so you *MUST* read the
frame table and save it, even if you're reading the file sequentially.
If Jnetstream doesn't do all that, it won't be able to read Network
Monitor-format files. If its architecture doesn't support doing that,
it will not be able to read those files until it's architecture is
changed to support doing that.
