Comment # 38
on bug 9607
from Guy Harris
(In reply to comment #36)
> Epan is extremely record based
Epan knows very little about Wiretap - the only place where the top-level code
in libwireshark uses Wiretap are
1) the address resolving code fetches address lists from the capture file
and
2) the frame data code fills in some frame_data structure fields based on
the packet header.
And there are views in which Wireshark should be able to show multiple entries
in the summary list for a single record from a capture file, and show a single
entry that spans multiple records from a capture file, for example (e.g., if
you're dissecting a protocol running atop TCP, and want each packet for that
protocol displayed with its own entry in the summary list), so there needs to
be some mechanism by which a dissector can, in effect, arrange that, at least
in some views, it gets to control what the entries are in the summary pane.
Such a mechanism could also work with Fileshark.
Note also that, if a given file-format dissector is being used directly in
Wireshark - rather than, say, having to dissect a JPEG being downloaded by
selecting it and saying "dissect this downloaded file in Fileshark in a
separate process" - it would be presenting file substructure in the tree for
the request or response containing the data, so file format dissectors
shouldn't rely on being handed subunits of the file.
You are receiving this mail because:
- You are watching all bug changes.