On Sep 2, 2011, at 12:53 AM, <[email protected]> <[email protected]>
wrote:
>>> Unfortunately there is no document online, but the structure is quite
>> simple, it's just a 32-bit value containing some bit fields:
>>
>> So a packet has a 32-bit value, followed by the Ethernet header,
> starting >with the destination MAC address?
>
> In order to have a nice Hex-Display, starting with the destination MAC
> address, we would like to put it *after* the Ethernet packet data.
That would have some problems:
1) if incl_len (caplen) is less than orig_len (len) due to a snapshot
length, the first thing to be lost is the NETANA_HEADER_T, so you won't be able
to support a snapshot length very well;
2) dissection is more of a pain - a Wireshark dissector would have to
wrap the packet data in a subset tvbuff and hand it to to Ethernet dissector, a
tcpdump dissector would have to cut the length short before calling the
Ethernet dissector rather than {printing,ignoring} the NETANA_HEADER_T and
handing the rest to the Ethernet dissector, and so on;
3) you have to read to the end of a detailed dissection to see the
header.
>>> uiLength:
>>> real frame length in bytes
>>
>> How does that differ from the pcap length field?
>
> It's there for historical reasons and provides the length of the
> captured data, it would be the same as the pcap length field.
If "the captured data" doesn't include the NETANA_HEADER_T, then it *wouldn't*
be the same as the pcap length field; both caplen and len in the pcap record
header (and the pcap-ng equivalents) include all the data in the record,
including pseudo-headers such as the NETANA_HEADER_T.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
