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:[EMAIL PROTECTED] Sent: Tuesday, April 15, 2003 12:59 PM To: Shaul Eizikovich; [EMAIL PROTECTED] 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.
