Skip to content

Conversation

Dimi1010
Copy link
Collaborator

@Dimi1010 Dimi1010 commented Sep 12, 2025

The PR adds heuristics based on the file content that is more robust than deciding based on the file extension.

The new decision model scans the start of the file for its magic number signature. It then compares it to the signatures of supported file types [1] and constructs a reader instance based on the result.

A new function createReader and tryCreateReader has been added due to changes in the public API of the factory.
The functions differ in the error handling scheme, as createReader throws and tryCreateReader returns nullptr on error.

Method behaviour changes during erroneous scenarios:

Scenario getReader createReader tryCreateReader
File not found N/A Throws exception Return nullptr
Unsupported format Return PcapFileDeviceReader Throws exception Return nullptr

Copy link

codecov bot commented Sep 12, 2025

Codecov Report

❌ Patch coverage is 89.20188% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.43%. Comparing base (e227b75) to head (af12d2f).

Files with missing lines Patch % Lines
Pcap++/src/PcapFileDevice.cpp 90.20% 12 Missing and 2 partials ⚠️
Tests/Pcap++Test/Tests/FileTests.cpp 85.48% 5 Missing and 4 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #1962      +/-   ##
==========================================
+ Coverage   83.41%   83.43%   +0.01%     
==========================================
  Files         311      311              
  Lines       55002    55197     +195     
  Branches    12098    12145      +47     
==========================================
+ Hits        45878    46051     +173     
- Misses       7889     7894       +5     
- Partials     1235     1252      +17     
Flag Coverage Δ
alpine320 75.91% <76.10%> (-0.01%) ⬇️
fedora42 75.86% <76.31%> (+<0.01%) ⬆️
macos-13 81.56% <80.33%> (-0.01%) ⬇️
macos-14 81.56% <80.33%> (-0.01%) ⬇️
macos-15 81.58% <81.92%> (-0.01%) ⬇️
mingw32 70.66% <80.95%> (+0.06%) ⬆️
mingw64 70.63% <80.95%> (+0.18%) ⬆️
npcap ?
rhel94 75.89% <76.31%> (+0.01%) ⬆️
ubuntu2004 60.16% <59.49%> (-0.01%) ⬇️
ubuntu2004-zstd 60.26% <56.57%> (+0.01%) ⬆️
ubuntu2204 75.83% <76.31%> (+0.02%) ⬆️
ubuntu2204-icpx 60.62% <61.53%> (-0.01%) ⬇️
ubuntu2404 75.90% <76.10%> (+<0.01%) ⬆️
ubuntu2404-arm64 75.59% <76.10%> (+0.02%) ⬆️
unittest 83.43% <89.20%> (+0.01%) ⬆️
windows-2022 85.44% <87.61%> (+0.16%) ⬆️
windows-2025 85.47% <87.71%> (+0.12%) ⬆️
winpcap 85.47% <87.71%> (-0.08%) ⬇️
xdp 53.35% <0.00%> (-0.21%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Dimi1010 Dimi1010 added the API deprecation Pull requests that deprecate parts of the public interface. label Sep 12, 2025
@Dimi1010 Dimi1010 marked this pull request as ready for review September 12, 2025 11:36
@Dimi1010 Dimi1010 requested a review from seladb as a code owner September 12, 2025 11:36
PTF_ASSERT_NOT_NULL(dynamic_cast<pcpp::PcapNgFileReaderDevice*>(genericReader));
PTF_ASSERT_TRUE(genericReader->open());
// ------- IFileReaderDevice::createReader() Factory
// TODO: Move to a separate unit test.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add the following to get more coverage:

  • Open a snoop file
  • Open a file that is not any of the options
  • Open pcap files with different magic numbers
  • Assuming we add a version check for snoop and pcap file: create temp files with bogus data that has the magic number but wrong versions

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3d713ab adds the following tests:

  • Pcap, PcapNG, Zst file with correct content + extension
  • Pcap, PcanNG file with correct content + wrong extension
  • Bogus content file with correct extension (pcap, pcapng, zst)
  • Bogus content file with wrong extension (txt)

Haven't found a snoop file to add. Do we have any?

Open pcap files with different magic numbers

Do you mean Pcap content that has just its magic number changed? Because IMO it is reasonable to consider that invalid format and fail as regular bogus data.

Assuming we add a version check for snoop and pcap file: create temp files with bogus data that has the magic number but wrong versions

Pending on #1962 (comment) .

Move it out if it needs to be reused somewhere.
Libpcap supports reading this format since 0.9.1. The heuristics detection will identify such magic number as pcap and leave final support decision to the pcap backend infrastructure.
@seladb
Copy link
Owner

seladb commented Sep 21, 2025

@Dimi1010 some CI tests fail...

@Dimi1010 Dimi1010 requested a review from seladb October 2, 2025 17:16
}
};

PTF_TEST_CASE(TestIFileReaderDeviceFactory_Pcap_MicroPrecision)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to test a real pcap file, maybe we can add syntethic files that have a different magic number to test all options?
We don't have to put them in PcapExample/file_heuristics, instead we can create vectors with the content std::vector<uint8_t> and save them to temp files

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, what would be the purpose? Just to test that it returns nullptr?
Doesn't TestIFileReaderDeviceFactory_Invalid already handle that?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the other possible magic numbers of a valid pcap file. Since it's not easy to find such pcap files, we can generate synthetic files that are not actually valid, but will look valid for the sake of the test

Copy link
Collaborator Author

@Dimi1010 Dimi1010 Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you want a spoofed pcap sample for just these:

// Libpcap 0.9.1 and later support reading a modified pcap format that contains an extended header.
// Format reference: https://wiki.wireshark.org/Development/LibpcapFileFormat#modified-pcap
0xa1'b2'cd'34,  // Alexey Kuznetzov's modified libpcap format
0x34'cd'b2'a1   // Alexey Kuznetzov's modified libpcap format (byte-swapped)

or for the byte swapped versions of micro and nano too?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest we have spoofed pcap samples for all options

Copy link
Collaborator Author

@Dimi1010 Dimi1010 Oct 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, if we really want to do a unit test on every magic number, this would be easier to do by exposing CaptureFileFormatDetector in the header under internal and unit testing on the passed std::istream content directly than to have a spoofed pcap file.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it so hard to create those spoofed pcap files just for the tests? 🤔

Copy link
Collaborator Author

@Dimi1010 Dimi1010 Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbf, no. I can have them done.

My idea is that the scenario would essentially test the content detection system and not the factory function creating the devices due to the fact that the devices would be "invalid." If the tests are done through factory function, it can't test to open the device, etc.

Having it done directly on the detection system would remove the requirements for external files as that operates on streams.

Of course, that comes with the tradeoff of having the detection system exposed in the headers as it needs to be referencable.


PTF_TEST_CASE(TestReaderFactory_Snoop)
{
constexpr const char* SNOOP_FILE_PATH = EXAMPLE_SOLARIS_SNOOP;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this variable is not needed, we can just use EXAMPLE_SOLARIS_SNOOP

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to have it to have a level of detachment from the global macro, if it needs to be changed later.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add createReader() to the tests?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added tests for the scenarios that throw. The success branches should be covered by tryCreate 🤔 ?

af12d2f

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can add one or two success cases, but not necessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API deprecation Pull requests that deprecate parts of the public interface. enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants