Comment # 9
on bug 8503
from Guy Harris
(In reply to comment #3)
> Hi Pascal,
>
> Thanks for taking a look at this patch. I have used the tvb_memcpy() for the
> same reason the dissect_linux_usb_pseudo_header() does use it: the protocol
> is host-endian (for x86 and x64 it's little-endian).
>
> The protocol is not fixed yet though. Do you think enforcing little-endian
> at the protocol level would be an advantage?
It appears that you are doing so:
http://desowin.org/usbpcap/captureformat.html
"All multi-byte values are LITTLE-ENDIAN."
As far as I know, Microsoft have never supported a big-endian-only instruction
set architecture, or supported a bi-endian architecture in big-endian mode,
with Windows NT. (Have they ever done so for Windows CE?) So if this is only
going to be used for traces from machines running Windows NT (as "irpId (offset
2) is merely a pointer to IRP casted to the UINT64" suggests might be the
case), then "host-endian" will mean "little-endian".
"host-endian" is a bit tricky. It requires that the byte order of the packets
somehow be reliably determinable.
If there is at least one multi-byte field the only values for which have at
least the upper 8 bits of the value zero, that could be used. That trick is
used for LINKTYPE_NULL/DLT_NULL, which has a 4-byte host-byte-order type field
that has an AF_ value; so far, no BSD-style OS has managed to require 2^24
different address family values. :-)
Alternatively, for headers that are only used in pcap and pcap-ng files, the
byte order of the file, for pcap, and the file section, for pcap-ng, could be
used to indicate the byte order of the host that wrote the file. *However*,
this means that if a file written by a host of one byte order is being read,
processed, and written by a host with the opposite byte order (we ignore
PDP-11's here :-)), the host-byte-order fields have to be byte-swapped before
being written. That's the case for LINKTYPE_USB_LINUX/DLT_USB_LINUX and
LINKTYPE_USB_LINUX_MMAPPED/DLT_USB_LINUX_MMAPPED; when reading a capture file,
libpcap and Wiretap both byte-swap the fields in question to match the host
byte order of the machine *reading* the file, so no byte swapping is required
when writing the file.
You are receiving this mail because:
- You are watching all bug changes.