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.
