Ethereal-dev: Re: [Ethereal-dev] tvb and dissector question.
> As I understand the source, read_packet() is the function which reads all
> frames from the child process
> which writes structures of one or more frames through the pipe in the
> filedescriptor which
> read_packet() get as a parameter.
No.
First of all, there is no guarantee that there *is* a child process.
The child process is there only if you're doing a live capture with
"Update list of packets in real time" specified.
Second of all, even if there *is* a child process, the frames aren't
read from the pipe between the processes; the only stuff that gets sent
from the child process to the parent process are
1) messages saying "N more packets have arrived"
or
2) messages saying an error occurred.
The parent process, in "Update list of packets in real time" captures,
reads from the capture file to which the child process is writing.
Third of all, "read_packet()", for better or worse, doesn't actually
read data from the capture file; packets are read from the capture file,
on the initial pass through the capture, with "wtap_read()".
"read_packet()" is the routine that, once the packet has already been
read, allocates a "frame_data" structure for it, partially fills it in,
constructs the protocol tree and runs a read filter against it *IF* a
read filter was specified and, if either
1) no read filter was specified
or
2) a read filter was specified and the packet passed the read
filter
adds the "frame_data" structure to the list of structures for all
frames, and calls "add_packet_to_packet_list()" to add the packet to the
list of packets in the summary display.
What you'd need, if you were to support reassembled IP datagrams, would
be, as per earlier mail, a *SECOND* summary display, showing reassembled
IP datagrams *AND* frames that aren't part of fragmented IP datagrams.
In order to reassemble IP datagrams, you'd either have to
1) save the raw packet data for fragments until you either have
all the fragments of the datagram or "time out" the
reassembly
or
2) save the offset in the capture file of the fragments, and use
"wtap_seek_read()" to read in the raw packet data for the
fragments.
2) will not work very well at all on gzipped files, as we currently do
*NOT* support very efficient random access to gzipped files. (We may do
so in the future, but that'd involve doing our own uncompression code -
zlib doesn't let us know where each compressed chunk in the file starts,
and we'd need to know that.)
