Paolo Abeni wrote:
On Fri, 2007-01-26 at 23:39 -0500, Charles Lepple wrote:
One problem is that the proto_tree_add_* calls set the little_endian
flag to true regardless of the endianness of the host.
This is a bug. Thanks for pointing it out. The attached patch should
solve it.
I renew the pledge for reviewing the endianess related stuff.
I modified the code to make the Linux-specific header a "pseudo-header",
so that it doesn't show up in the packet data; instead, it appears as a
data structure, in host byte order.
This means that the values from that are put into the protocol tree with
calls that take values as arguments, rather than fetching the values
from the protocol tree, and those values are expected to be in host byte
order (i.e., they're expected to have been extracted already from the
packet, or computed, or fetched from a pseudo-header or from some data
structure internal to the dissector), so that handles that case.
In addition, it means that if you write out packets from a Linux USB
capture, the pseudo-header is written out in the byte order of the host
writing the data, not in the byte order it had in the capture - which is
what you want, because the file header will also be written out in the
byte order of the host writing the data.
I was able to read your capture file on my big-endian PowerBook - and
was able to save one of the packets out, and read that file back in.
You might want to check to make sure that file (written out in
big-endian format) can be read by your little-endian machine; I've
attached that capture.
I also fixed some other issues that I saw when reading the capture - for
example, some fields from the USB packet were being read in big-endian
format rather than little-endian format, and control packets were being
interpreted as standard requests even if the type wasn't "Standard".
I've checked that version in.
It might be interesting to make it handle the old format as well.
Attachment:
onepacket.pcap
Description: Binary data
