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