Neha Chahal wrote:
The format of the file is binary
"Binary" isn't a format for a packet capture; there are several capture
file formats, all of which are binary, but they're not all the same.
What *specific* binary format is it?
Is this some standard format (libpcap format as used by
tcpdump/WinDump/Wireshark/etc., DOS Sniffer format, Windows Sniffer
format, Microsoft Network Monitor format, Sun snoop format, etc.), or is
it some format you or somebody else has created?
and the protocol is LEA.
What protocol is that?
It is a protocol at the application layer. So it is the top most protocol.
What protocol does it run atop? TCP? UDP? Some other protocol?
So I have to implement both. Is that true?
Yes, you have to implement both read and seek_read functions.
So my read routine is returning the packet in wth->frame_buffer. But I
have not implementes the seek_read. The README.dev says "implement
seek_read if necessary". What does this mean?
It means that the documentation hasn't been updated to indicate that
there's no longer a "default" seek_read routine that a file format
module can use, so modules always have to have their own seek_read
routine. (I've just checked in a change to wiretap/README.developer to
fix that.)
When is it necessary?
Always.
My packets dont have any transport layer headers. They are in the
format I have specified in the dissector. So this is the way my packet
looks like.
fixed header
payload header
variable length payload
So are you saying that the *ONLY* protocol in the packet is this "LEA"
protocol?
In the dissector I have given protocol details starting from the fixed
header. So the packet that I return in the wth->frame_buffer should
start from the fixed header to the end of the payload. Is this
correct?
Yes.
Where should the data offset point. At the payload header or at the
fixed header ?
At the fixed header - it's the offset to which the seek_read routine
would need to seek to get the entire packet.
