> I have had some limited success. The attached patch can be used to make
> wiretap load a Mac etherpeek V7 format file. All data appears to get
> loaded. In fact the summary pane shows the TCP packets correctly.
> Unfortuantely the lower pane shows a corrupt IEEE 802.3 packet and gets no
> further.
The summary pane entry is constructed on the first pass through the
capture, when a sequential read is being done.
The protocol tree pane is constructed later; Ethereal uses the value
supplied by Wiretap as the offset of the frame data, and passes that on
to the code in Wiretap to do random-access reads.
If that offset isn't correct, the data it reads won't be the contents of
the packet, and the protocol tree will not display correctly.
> If I was getting nothing I would understand that I had messed up. However I
> don't understand why the top pane works and the bottom one does not. Can
> anyone explain what I have done wrong!
You're probably not returning the right offset.
In fact, "etherpeek_open()" is *NOT* modifying "wth->data_offset",
unlike the "XXX_open()" routines in most if not all other capture-file
reader modules, which set it to be the current offset in the file.
This means that "wth->data_offset" will be the offset in the file
*minus* the length of the header stuff read by "etherpeek_open()", and
thus the offsets returned by "etherpeek_read_m7()" will be incorrect.
You should, for example, add "sizeof(ep_hdr.master)" to
"wth->data_offset" after reading "ep_hdr.master", and do the same sort
of thing after all *other* reads in "etherpeek_open()".
If, after fixing that, it still doesn't work, there are probably other
places where the offset isn't being maintained properly, and you'll have
to find and fix those as well.
