On Tue, Apr 15, 2003 at 02:41:29PM +0300, Shaul Eizikovich wrote:
> I'm writing a dissector that will run on the output of "fw monitor". This
> output is almost identical to "snoop" with some minor differences.
Is that the same was the monitor files that packet-fw1.c handles?
> The relevant data being: every packet is replicated several times, with
> everything but the MAC address staying unchanged. The replicated sub-packets
> are guarantied to be sequential and continuous.
That's true only if users are guaranteed not to run editcap on a
capture, or selectively save packets from a capture, or if people
guarantee that captures of that sort won't ever be supplied to Ethereal.
> When my dissector is called for the first time, it creates (for each
> sub-packet) a data structure. It also gets some data from the previous
> sub-packet's data structure, if the previous sub-packet belongs to the same
> original packet. This way, the current sub-packet accumulates data from all
> relevant previous sub-packets.
> I also need to know whether this is a LAST sub-packet. Naturally, during the
> first pass, this is an impossible task.
>
> When my dissector is called for the second time, during FIND operation, it
> is able to determine if a sub-packet is last or not by looking into the data
> structure of the next sub-packet, if such a sub-packet exists.
> I assumed that if a next sub-packet does not exist, the next field will be
> NULL.
If by "the next field" you mean the "next" field in a "frame_data"
structure, then the next field will be null only for the last frame in
the capture; it has nothing to do with the "fw monitor" notion of
subpackets, i.e., the assumption is true iff "a next sub-packet does not
exist" means "this is the last frame in the capture".
> Also, I assumed that if the next packet exists but for some reason its data
> structure is missing, p_get_proto_data() will return NULL.
> Wrong, sometimes I get a crash because the next sub-packet does exist, and
> p_get_proto_data() returns an address which is illegal.
"p_get_proto_data()" will return a non-null value only if
the "pfd" member of the "frame_data" structure is non-null;
it's the beginning of a GSList of "frame_proto_data" structures
and there's an element in that list that has the specified
protocol index and a non-null data pointer;
or
"g_slist_find_custom()" is buggy in the version of GLib you're
using.
Assuming a non-buggy GLib, "p_get_proto_data()" will return an illegal
address only if some code put it there. All your calls to
"p_add_proto_data()" *do* have a valid pointer as the third argument,
right?
