[pcap-ng-format] Does anyone actually generate the epb_hash field today?

Jasper Bongertz jasper at packet-foo.com
Thu Aug 27 23:47:42 UTC 2015


Friday, August 28, 2015, 1:25:46 AM, Hadriel Kaplan wrote:

>> I don't use the current epb_hash option, but I can see some use cases.

> Oh I'm not debating there might be some use for it
> somewhere/somehow/someday - just asking if anyone's ever implemented
> it. (Mostly because I'm trying to get the doc to a point we can submit
> it to the IETF, and thus need to remove or clear up things that aren't
> specified well enough to implement in an interoperable fashion.)

Agreed.

>> The epb_hash could be a hash, signature, or digest over some part of the
>> packet 'payload'. This could be just the IP payload, the whole IP datagram,
>> or the entire Ethernet frame for example. The purpose would be to accelerate
>> the detection of 'duplicate' packets/payloads. These commonly occur in some
>> SPAN (or other Network Packet Broker) configurations, when capturing from
>> multiple VLANs, or when capturing at multiple points in a network
>> simultaneously.
>> Duplicates might be excluded from TCP analysis to avoid invalid
>> retransmission detection, or may be leveraged to measure network/equipment
>> latency.

> Sure, but programs which perform duplicate-packet detection and
> removal already do their own calculations and decisions, based on
> various factors/criteria. Why do they need the file to tell them
> something they can figure out on their own, and will ignore anyway
> unless it meets their exact criteria?

Especially since there are many ways of doing deduplication, and it's
not a time critical task where precalculated hashes could offer
any kind of advantage.

> Or are you saying it's a hash of the *original* packet data, which
> might not all be in the Packet Data field due to a shorter
> snaplen/capture-length?  I don't believe that's the case, because the
> current text in the doc says one of the purposes for it was for
> "reliable data transfer between the data acquisition system and the
> capture library". (but I may be reading too much into that)

I think it's something that was considered a use case when the
original draft was written down but turned out to be never used so far
as the benefits are quite limited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150828/b7893d5e/attachment.bin>


More information about the pcap-ng-format mailing list