I was probably unclear because I was trying to write a short entry.
Let me elaborate:
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.
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.
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.
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.
I hope my problem now looks less silly.
Thanks
Shaul
-----Original Message-----
From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
Sent: Tuesday, April 15, 2003 12:59 PM
To: Shaul Eizikovich; ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Crash when using "Per packet information"
----- Original Message -----
From: "Shaul Eizikovich"
Sent: Tuesday, April 15, 2003 7:36 PM
Subject: [Ethereal-dev] Crash when using "Per packet information"
> I have been writing a new dissector where adjacent packets are grouped
> according to some accumulative data.
> To do so, I employed the p_add_proto_data() and p_get_proto_data()
function
> pair.
How can that work?
In the sequence of packets, how do you guarantee that no unrelated packets
creep in betweent eh packets you are interested in?
Do you do this to keep track of the packets in order to reassemble them into
larger PDUs?
If so there is extensive infrastructure already in ethereal to do
reassembly.
Do you need to separate packets belonging to different conversations? If so
have you looked
at the conversdation infrastructure?
>
> In short:
> Crash when redissecting.
> Important data: I do not pass pinfo->fd, rather I pass pinfo->fd->prev as
> first parameter of p_get_proto_data()
Why do you need to keep information about the previous packet seen in the
capture file?
What guarantees this packet to be relevant?
There is a simple way to make sure a certain code is only excecuted once for
each packet
but please explain exactly why you look at the previous packet that happens
to occur in the capture file.
I want to know you really want the previous packet in the capture as opposed
to the previous relevant packet in the conversation.
