Ronnie Sahlberg wrote:
>
>
> Question:
> Assuming I have a complete IP-packet in a buffer.
> How can I create proper tvb,pinfo,tree structures so I can call dissect_ip()
> (or any other dissector)?
> I want this packet to be displayed in the top-tree view, not as a subtree
> inside the ip-tree for a fragmented ip-packet.
> Help me with this and you will have defragmentation in the ip-layer in
> ethereal.
> End Question.
You can't do this from inside a dissector. I think the right approach
is, from
a higher level, to create a new frame_data list, or at least augment
this
list by *adding* your new packet. You'd have to add new fields to
frame_data
to be able to differentiate packets from a file and these reconstructed
packets.
>
> (the buffer is almost, but not really a proper IP-packet. eg MF-bit in flags
> is cleared, offset is set to 0,
> the checksum is set to 0 (I will indicate to dissect_ip() that this is a
> magic packet which should not
> care for these fields))
An alternate approach would be to create a new protocol for this
"reconstructed" IP
packet. The only information that really makes sense in this RECON_IP
header is:
Protocol, Source Address, and Destination Address. You might add a new
Total Length,
too. But the rest can be thrown away.
Furthermore, the lower-level protocols (ethernet) don't make sense for
this
RECON_IP packet either. Besides making RECON_IP a new protocol, I
propose
using it at the bottom-most layer (the link-layer). That is, we could
either
set aside a range of WTAP_ENCAP_* numbers for application-defined
protocols,
or we could add it to Wiretap. The new packet would *start* with a
RECON_IP
header, and thus, have a WTAP_ENCAP_RECON_IP encapsulation type.
The dissect_recon_ip() dissector would exist *inside* packet-ip.c, so
that
it could easily use the hf_ip_* fields, *but*, it would register itself
to the "wtap_encap" dissector table (see dissect_frame()), not to
anything
else.
Thoughts?
--gilbert
