Re: usbmon: size of different fields?

[Guy Harris <guy () alum mit edu>]

On Nov 9, 2010, at 8:25 AM, Maynard, Chris wrote:

> Not sure why I don't see this message posted on gmane?
>
> Anyway, I see you received a few responses already elsewhere:
> -> http://lkml.org/lkml/2010/11/9/243

...in which Pete Zaitcev says:

> Do be careful here, because the struct you're talking about is a part
> of API, not a network stream. Its field sizes are rigidly defined, but
> the byte order is host! You MUST NOT attempt to store it in pcap files.

Somebody should perhaps let him know that ship has already sailed - they *are*, for better or worse, being stored in 
pcap files.

> -> http://www.spinics.net/lists/linux-usb/msg38480.html
>
> But I don't think those responses are technically correct. With the C standard, there are no guarantees except for 
> relative sizes, ie., char <= short <= int <= long, although if the OS is POSIX-compliant, then you can sleep well at 
> night knowing CHAR_BIT is defined as 8 in <limits.h>.

What, no POSIX-compliant OSes for the Univac mainframes?  (Yes, there was a UNIX port at one point.)  I'd list the 
PDP-10, but you could have 4 8-bit bytes plus 4 spare bits per word if you wanted to....

In practice, the vast majority of UN*X systems are either ILP32, with 8-bit char, 16-bit short int, 32-bit int and long 
int and, these days, 64-bit long long int, or LP64, with smaller sizes the same and 64-bit long int.  Windows is either 
ILP32 or LLP64; the latter is like LP64 except that long int is 32-bit but some other size is 64-bit (the LL 
nonwithstanding, I don't think Microsoft uses "long long int").  So, while the responses aren't technically correct in 
general, they're probably correct for Linux (except maybe for some oddball embedded processors) and all other modern 
UN*Xes, as well as for Windows.

> But there's no guarantee that every platform is POSIX-compliant or that the char size is guaranteed to be 8 bits on 
> non-POSIX-conforming platforms, although I can't imagine that Wireshark runs today on any platform where that isn't 
> the case.
>
> As for int, I suspect that most platforms have 32-bit ints, but again, there are no guarantees.

I can testify that I, at least, have put no effort into making sure libpcap would work on platforms other than ILP32, 
LP64, or LLP64; I would not be surprised to find that the GLib and GTK+ developers haven't, either.  That alone makes 
it unlikely that Wireshark will run on any other type of platform, and I doubt many Wireshark developers have put much 
effort into making sure the Wireshark code handles any programming models other than those.

> P.S. The endian-ness is not an issue because of the libpcap header's magic number.

...as long as, when a program on a machine with a particular byte order reads a file written on a machine with the 
opposite byte order and writes out packets from that file to a pcap or pcap-ng file, all the multi-byte host-byte-order 
fields are byte-swapped to be in the appropriate byte order for the output file.

That is *NOT* currently being done by libpcap or Wireshark for the iso_rec fields that overlap that USB setup 
information or any of the fields in the isochronous descriptors.  libpcap *does* byte-swap the other fields when 
reading a capture, so all those fields appear, when reading a file, to be in the byte order of the host that's reading 
them (see swap_linux_usb_header() in pcap-common.c in the trunk of libpcap), and Wireshark's Wiretap does the same (see 
pcap_process_linux_usb_pseudoheader() in wiretap/pcap-common.c in the Wireshark source).  This means that you might 
have trouble reading the isochronous information in, for example, a capture file written on a PowerPC machine, and then 
processed on an x86 machine by a program that reads and writes packets (whether it's tcpdump or Wireshark/TShark 
or...), even if we add the additional byte-swapping to libpcap and Wireshark - the damage might already have been done.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe