On Thu, Mar 01, 2001 at 09:31:44AM +0600, Diwakar Shetty wrote:
> 3) How do I initialise the second arguement "packet_info *pinfo".
>
> The reason I am asking is because in our project the PPP packets are
> not only compressed but also are spilt into more than one packets. Hence
> it is NOT that for every packet we receive we call "dissect_ppp". Rather
> after receiving "many" spilt compressed PPP packets, we REASSEMBLE,
> UNCOMPRESS and then pass it on to "dissect_ppp".
Note that Ethereal dissectors can "receive" packets in a random order.
They will receive them in time order on the first pass through the
capture file. However, once the capture file has been read in, the user
can randomly click on frames as they choose, so that the dissector could
be called on frame 17, then frame 34, then frame 5, then frame 255, then
frame 99, etc..
Your dissector would have to be able to handle that.
Note also that Ethereal has no infrastructure, at present, for updating
the summary pane entry for a frame after the first part of the
dissection is done, e.g. when the larger packet of which it's a part is
reassembled and that larger packet is dissected.
Furthermore, its code for doing display filtering also currently has no
mechanism for handling the case where part of the protocol tree for the
frame cannot be constructed until the larger packet of which that frame
is a part is reassembled.
For that matter, its code for *displaying the protocol tree for a
packet* has no mechanism for handling that.
> However it seems that "pi" (the global packet_info variable) seems
> to be initialised/updated in various places.
>
> So it seems that the only way is to go through all the files ( till
> the point "tvb_new_real_data()" is called in "packet.c") and see in
> which all places "pi" is being updated.
>
> Or am I missing something crucial here ??
Yes, you're missing the fact that Ethereal, at present, lacks some
crucial mechanisms necessary to support reassembly of packets, and
therefore that dissectors that reassemble packets aren't going to work
very well, if at all, and therefore that the dissector you're trying to
write isn't going to work very well, if at all.
