lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CD9A96D.1010306@freemail.hu>
Date:	Tue, 09 Nov 2010 21:05:01 +0100
From:	Németh Márton <nm127@...email.hu>
To:	Pete Zaitcev <zaitcev@...hat.com>
CC:	linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Developer support list for Wireshark 
	<wireshark-dev@...eshark.org>
Subject: Re: usbmon: size of different fields?

Pete Zaitcev wrote:
> On Tue, 09 Nov 2010 07:40:36 +0100
> Németh Márton <nm127@...email.hu> wrote:
> 
>> I'm looking at the struct mon_bin_hdr and struct mon_bin_isodesc in file
>> f=drivers/usb/mon/mon_bin.c
> 
> 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
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5370

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
  https://bugzilla.kernel.org/show_bug.cgi?id=22182

	Márton Németh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ