Wireshark · Wireshark-dev: Re: [Wireshark-dev] “bytes on wire” vs. “bytes captured”

[Stephen Donnelly <Stephen.Donnelly@xxxxxxxxxx>]

We had a long discussion about adding fields to Wireshark to track pseudo-header and pseudo-trailer metadata lengths back in 2016.

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12526

For instance in cases where a packet broker adds extra bytes 'on the wire' before capture, or the capture device itself adds metadata in extra headers.

The current definitions of libpcap derived len and caplen are insufficient to distinguish these bytes.

Regards,
Stephen

-----Original Message-----
From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jasper Bongertz
Sent: Saturday, 20 July 2019 4:30 AM
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] “bytes on wire” vs. “bytes captured”

Hi,

so if I get this right you expect to end up with a frame where length of the original content is less than what ends up in the pcap because meta data is added? This usually happens by adding a trailer to the Ethernet frame, e.g. some TAPs do that to add high precision timestamps and other info. Which of course increases the total length, because it's now part of the frame. And Wireshark can parse that info if it knows/assumes that its attached.

If you have a capture device that wants to write additional detail about a frame to the capture file you should choose pcapng instead. pcapng allows storing a lot of additional information for each frame in the frame headers. This is a much cleaner way, instead of merging frame and non-frame bytes together - especially since other tools that can process pcap won't be able to distinguish between the two.

If using frame headers like the ones in pcapng is not possible - why not? :-)

Cheers,
Jasper

Friday, July 19, 2019, 2:52:57 PM, you wrote:

> Hi,

> I was wondering about a fact regarding the reported frame lengths in Wireshark.

> The frame dissector states “bytes on wire” and “bytes captured” values.
> I understand that these values where initially generated by the values 
> caplen and len in the pcap packet header as follows:
> struct pcap_pkthdr {
>                 struct timeval ts;              /* time stamp */
>                 bpf_u_int32 caplen;       /* length of portion present */
>                 bpf_u_int32 len;              /* length this packet (off wire) */
> };

> This is useful if the capture device cuts off data but wants to report 
> the original length and thus tvbuff also provides the values length and reported_length.
> struct tvbuff
> …
>                 /** Amount of data that's available from the capture
>                 * file.  This is the length of virtual buffer (and/or
>                 * real_data).  It may be less than the reported
>                 * length if this is from a packet that was cut short
>                 * by the capture process.
>                 *
>                 * This must never be > reported_length or contained_length. */
>                 guint                                     length;

>                 /** Amount of data that was reported as being in
>                 * the packet or other data that this represents.
>                 * As indicated above, it may be greater than the
>                 * amount of data that's available. */
>                 guint                                     reported_length;
> ….
> };

> Thus, as stated in the comment above length never must be larger than 
> reported_length, which is true if the capture device drops data.

> Now my question: I would be very useful to use pcap’s caplen and len 
> values to report original packet length while a capture device adds 
> additional data to a frame, for example a header containing some more details about the frame itself.
> In such a case, I would expect that pcap’s len would be set to the 
> original’s frames length, while caplen would be frame length plus 
> header length. That a header is present and how it can be decoded is detectable by the link layer type.

> Unfortunately, when I tested this, Wireshark truncates 
> reported_length, cutting of the data buffer which container the additional header information.

> Is there any reason for that type of implementation?
> It would be really great if Wireshark would report a “bytes on wire” 
> value which actually shows the original frames length on wire, while 
> “bytes captured” would show the larger value including the header part.

> BR,
> Holger


> Hilscher Gesellschaft für Systemautomation mbH   |  Rheinstrasse 15  |  65795
> Hattersheim  |  Germany  |  www.hilscher.com<http://www.hilscher.com>
> Sitz der Gesellschaft / place of business: Hattersheim  |  
> Geschäftsführer / managing director: Dipl.-Ing. Hans-Jürgen Hilscher 
> Handelsregister / commercial register: Frankfurt B 26873  |  Ust. 
> Idnr. / VAT No.: DE113852715 Registergericht / register court: 
> Amtsgericht Frankfurt/Main

> Important Information:
> This e-mail message including its attachments contains confidential 
> and legally protected information solely intended for the addressee. 
> If you are not the intended addressee of this message, please contact 
> the addresser immediately and delete this message including its 
> attachments. The unauthorized dissemination, copying and change of 
> this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

> Wichtiger Hinweis:
> Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und 
> rechtlich geschützte Informationen, die nur für den Adressaten 
> bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so 
> teilen Sie dies bitte dem Absender umgehend mit und löschen Sie diese 
> Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen 
> von Kopien und jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails.



jasper@xxxxxxxxxxxxxx


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

Attachment: smime.p7s
Description: S/MIME cryptographic signature