mailing list archives
Re: usbmon: size of different fields?
From: Németh Márton <nm127 () freemail hu>
Date: Tue, 09 Nov 2010 21:05:01 +0100
Pete Zaitcev wrote:
On Tue, 09 Nov 2010 07:40:36 +0100
Németh Márton <nm127 () freemail hu> wrote:
I'm looking at the struct mon_bin_hdr and struct mon_bin_isodesc in file
Actually you're supposed to be looking at Documentation/usb/usbmon.txt.
If there is a discrepancy between the usbmon.txt and mon_bin.c, I want
to know about it.
There is only minor differences between Documentation/usb/usbmon.txt and
drivers/usb/mon/mon_bin.c . These are as follows:
- the busnum field is u16 in txt and "unsigned short" in c file
- the field "length" (in txt) has different name "len_urb" (in c)
The ISO description structure is missing from the txt description but
this can be found in drivers/usb/mon/mon_bin.c .
As far as I understand u64, s64, u32 and s32 have always fixed bit lengths.
What about "unsigned char", "char", "unsigned int" and "int"? May their size in bits
differ in different architecture?
No they may not. They sizes are always the same on any architecture,
as long as Linux supports it.
So to summarize, the following table is valid on all architectures. Right?
type in Linux | size in bits
unsigned char | 8bit
char | 8bit
unsigned int | 32bit
int | 32bit
I'm asking this because I was dealing with the USB packet dissectors for Wireshark
and it is possible to capture the USB traffic on one computer and then transfer
the file to another computer.
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.
OK, that's clear, the byte order of the API structure fields are in "host endian"
order. The API structures are already saved by Wireshark into file for quite some
time. There is already a discussion on endianness topic together with ISO descritors:
Wireshark Bug 5370 - Add support for USB isochronous
There is an other problem which I found about capturing ISO USB packets with
mmap, this problem seems to be originated from Linux kernel:
Kernel Bug Tracker Bug 22182 - usbmon: completed ISO packet content is not fully arriving with mmap
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Re: usbmon: size of different fields? Alan Stern (Nov 11)