PCAPNG: Adding SHB Options

[LarsV33]

This patch allows to initialize the PcapNgWriter with Hardware, OS, and User Application. This information is written to the pcapng SHB.

[guedou]

Thanks for this PR. Could you add unit tests, for example at

scapy/test/regression.uts

Line 2258 in ef72e1d

?

Also, can you point us with the documentation of these blocks?

[LarsV33]

Thanks for this PR. Could you add unit tests, for example at

scapy/test/regression.uts

Line 2258 in ef72e1d

?

I gave it a try. Without a reader hard to read back.

Also, can you point us with the documentation of these blocks?

This is part of the regular pcapng specification. These options are missing in the scapy implementation.

I guess the best pcapng spec is the upcoming rfc:
https://www.ietf.org/archive/id/draft-ietf-opsawg-pcapng-04.html#name-section-header-block

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.86%. Comparing base (ef72e1d) to head (41d1a2c).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4865      +/-   ##
==========================================
+ Coverage   80.48%   80.86%   +0.37%     
==========================================
  Files         368      368              
  Lines       90255    90269      +14     
==========================================
+ Hits        72645    72998     +353     
+ Misses      17610    17271     -339     

Files with missing lines	Coverage Δ
scapy/utils.py	73.57% <100.00%> (+0.92%)	⬆️

... and 22 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[guedou]

Thanks for pointing out the spec! I forgot about it.

The RawPcapNgReader already supports reading these options, that probably better to tweak it and use for the unit tests, see https://github.com/secdev/scapy/blob/master/scapy/utils.py#L1752

[guedou]

@LarsV33 I push the changes to the unit tests. How does that look?

[gpotter2]

How many options are there in total?

Do we want to make an API? I see this as "someone will always want an option we don't have".

Two propositions:

• pass a list of PCAPOption (or similar) structures with the type and value
• have an API like addoption(<some enum type>, <value>)

Or similar. WDYT @guedou

[guedou]

That's a tricky question, because it depends on block types.

I agree that the current design don't scale well. I will have a look at something better to easily add new options (likely an options argument to the object constructor).

I don't recall that the PCAPng draft that I implemented had that many options.