Wireshark · Wireshark-dev: Re: [Wireshark-dev] USB URB hex bytes not shown

["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

But in this case, wiretap isn't supplying any new information as far as I can tell.  To me, it looks like the only differences between what is displayed in the "packet details" pane and the content available in the pcap_usb_header structure are that the two time fields, ts_sec and ts_usec have been removed, and that the pcap_usb_setup isn't displayed or appears to be incorrectly displayed.

So, is there any real reason to remove those two time fields?  Presumably if they were simply left in and displayed like all the other fields, then wiretap wouldn't have to treat the pseudo header any different for DLT_USB_LINUX.

Here's the raw data as shown by hexdump:
hexdump -C  usburbex.pcap
00000000  d4 c3 b2 a1 02 00 04 00  00 00 00 00 00 00 00 00  |................|
00000010  00 10 00 00 bd 00 00 00  65 62 b6 4b 10 14 0c 00  |........eb.K....|
00000020  30 00 00 00 30 00 00 00  40 ab ea 25 00 81 ff ff  |0...0...@..%....|
00000030  43 03 02 02 06 00 2d 3e  65 62 b6 4b 00 00 00 00  |C.....->eb.K....|
00000040  10 14 0c 00 00 00 00 00  1d 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00                           |........|
00000058

And here's the comparison of pcap_usb_header fields vs. what Wireshark displays:

pcap_usb_header fields       Wireshark displays in "packet details" pane
u_int64_t id                 URB id: 0xffff810025eaab40
u_int8_t event_type          URB type: URB_COMPLETE ('C')
u_int8_t transfer_type       URB transfer type: URB_BULK out (0x03)
u_int8_t endpoint_number     Endpoint: 0x02
u_int8_t device_address      Device: 2
u_int16_t bus_id             URB bus id: 6
char setup_flag              Device setup request: not present ('-')
char data_flag               Data: not present ('>')
int64_t ts_sec               ===> Not displayed <===
int32_t ts_usec              ===> Not displayed <===
int32_t status               URB status: Success (0)
u_int32_t urb_len            URB length [bytes]: 29
u_int32_t data_len           Data length [bytes]: 0

                              ===> Displayed incorrectly <===
pcap_usb_setup setup         [bInterfaceClass: Unknown (0xffff)]
  u_int8_t bmRequestType
  u_int8_t bRequest
  u_int16_t wValue
  u_int16_t wIndex
  u_int16_t wLength

And of course the "packet bytes" pane only displays the following, which happens to be the real pcap_usb_setup data, but is not very obvious since the other bytes are missing.  In fact, it's downright confusing:
0000 00 00 00 00 00 00 00 00                               ........

How that last part for pcap_usb_setup is displayed appears to be a bug (isn't it?) because not only is there no "bInterfaceClass" field in the pcap_usb_setup structure, the data of 0xffff is just wrong.  Or is that the part being added by wiretap for some reason?  If it is, I can't figure out why or why the rest of the pcap_usb_setup data isn't being displayed in the "packet details" pane at all.

I don't know, I can't figure out what value wiretap brings by monkeying with the pcap_usb_header data.  And even if it does do some monkeying, I still can't understand why the original raw bytes can't be shown.  As another example/comparison, if I run "tcpdump -r urbusbex.pcap -XX", I get:
reading from file usburbex.pcap, link-type USB_LINUX (USB with Linux header)
17:32:21.791568 BULK COMPLETE from 6:2:2
        0x0000:  40ab ea25 0081 ffff 4303 0202 0600 2d3e  @..%....C.....->
        0x0010:  6562 b64b 0000 0000 1014 0c00 0000 0000  eb.K............
        0x0020:  1d00 0000 0000 0000 0000 0000 0000 0000  ................

These are the 48 bytes I would expect to see in Wireshark's "packet bytes" pane.
- Chris
P.S. As always, thanks Guy for your insights ... and your patience as I struggle to understand what is going on here & why.

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Thursday, April 08, 2010 2:57 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] USB URB hex bytes not shown


On Apr 8, 2010, at 11:45 AM, Maynard, Chris wrote:

> Hmm, I'm still confused.  Byte order aside, the "packet details" pane contains information from the "pseudo-header".

Yes, that's the case for most if not all of the packet encapsulations that include a pseudo-header.

> For example, in the example capture file I sent, the URB id filed is displayed as:
> 
> 	URB id: 0xffff810024eaab40
> 
> But nowhere in the "packet bytes" pane do those bytes appear.

Data that Wiretap supplies in a pseudo-header isn't in the raw packet data it supplies.

> Contrast this with the attached example of a Linux cooked capture where the cooked pseudo header is present

The problem is that "pseudo-header" has two meanings here:

	1) in a capture file, some raw packet data consists of a "pseudo-header" containing packet metadata - for example, the Prism, AVS, and Radiotap headers for 802.11 radio information is a "pseudo-header" in that sense - followed by the real packet data;

	2) in the Wiretap library, the routines for reading packets can supply both a "pseudo-header" in the form of a data structure and packet data in the form of a block of bytes.

The pseudo-header for 1) may, or may not, be supplied as a pseudo-header for 2).  The pseudo-header for 2) may, or may not, have appeared as a pseudo-header for 1) (it might, instead, have come from metadata in the capture file format).

> Selecting each of the fields within the cooked header highlights the corresponding bytes in the "packet bytes" pane.  I guess I would expect the same behavior for DLT_USB_LINUX as we get for DLT_LINUX_SLL.

For DLT_LINUX_SLL, the pseudo-header for 1) is supplied as part of the packet data; for DLT_USB_LINUX, it's supplied as a pseudo-header for 2).  Again, whether that's the right thing to do is another matter.

(Note also that, for any packet format for which the pseudo-header for 1) is supplied as part of the packet data, any calculation, such as a bandwidth calculation, that counts all bytes of packet data will give the wrong answer.  This is not necessarily an argument in favor of supplying the pseudo-header for 1) as a pseudo-header for 2), but it *is* an argument for, if it's *not* supplied as a pseudo-header for 2), for Wiretap somehow indicating how much of the raw packet data is a pseudo-header, or for *all* bandwidth calculations - including those done by capinfos! - knowing enough about the raw packet data format to be able to determine how much of the packet data is a pseudo-header and not including it in the calculation.)
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and 
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.