Re: USB URB hex bytes not shown

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

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.)
___________________________________________________________________________
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