Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

output: Add linktype name #11584

Closed
wants to merge 1 commit into from
Closed

output: Add linktype name #11584

wants to merge 1 commit into from

Conversation

jlucovsky
Copy link
Contributor

@jlucovsky jlucovsky commented Jul 30, 2024

Continuation of #11564

Issue: 6954

This commit adds the linktype name to the output stream. The name is determined from the pcap utility function pcap_datalink_val_to_name

Link to ticket: https://redmine.openinfosecfoundation.org/issues/6954

Describe changes:

  • Include the linktype name alongside linktype
  • Update the schema with linktype_name

Updates:

  • Rebase
  • Expanded linktype name validation in s-v tests ensuring that testing on 6 and 7 continues to pass.

Provide values to any of the below to override the defaults.

SV_BRANCH=OISF/suricata-verify#2006

Issue: 6954

This commit adds the linktype name to the output stream. The name is
determined from the pcap utility function pcap_datalink_val_to_name
@jlucovsky jlucovsky requested review from victorjulien and a team as code owners July 30, 2024 12:43
Copy link

codecov bot commented Jul 30, 2024

Codecov Report

Attention: Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.49%. Comparing base (da1645b) to head (2bb32d0).
Report is 26 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11584      +/-   ##
==========================================
- Coverage   82.50%   82.49%   -0.02%     
==========================================
  Files         923      923              
  Lines      248721   248724       +3     
==========================================
- Hits       205215   205175      -40     
- Misses      43506    43549      +43     
Flag Coverage Δ
fuzzcorpus 60.47% <66.66%> (-0.04%) ⬇️
livemode 18.63% <0.00%> (+<0.01%) ⬆️
pcap 44.07% <0.00%> (+0.01%) ⬆️
suricata-verify 61.76% <66.66%> (-0.02%) ⬇️
unittests 59.07% <0.00%> (+<0.01%) ⬆️

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

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 21775

@catenacyber
Copy link
Contributor

I left some comments on the SV test

@jlucovsky
Copy link
Contributor Author

I left some comments on the SV test

Addressed in new PR: OISF/suricata-verify#2006

Comment on lines 3466 to +3468
"linktype": {
"type": "integer"
},
Copy link
Member

Choose a reason for hiding this comment

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

Any thoughts on deprecating this field given its non-portable?

Copy link
Contributor

Choose a reason for hiding this comment

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

How is it not portable ? (the link type in a pcap is encoded as some integer, is it not ?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The mapping between the linktype value and name is implementation dependent. Most of the mappings are the same but not all.

Copy link
Contributor

Choose a reason for hiding this comment

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

So, when reading a pcap, we read its linktype as an integer, but if we do not know on which implementation it was captured, this linktype may mean different things, correct ?

So, still good to log the linktype as it is the thing we know from the pcap file... correct ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes; we use the pcap library on the host running Suri to interpret the linktype value

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems that we don't document packet_info our docs (or I couldn't find it). So I'm thinking we can add a ticket to document it, and include in the task registering this aspect of the linktype...

},
"linktype_name": {
"type": "string",
"description": "the descriptive name of the linktype"
Copy link
Contributor

Choose a reason for hiding this comment

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

Should the description mention the non-portability stuff ?

Copy link
Contributor

Choose a reason for hiding this comment

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

#11584 (comment)
I think we should add this to our userguide 🤔

Copy link
Contributor

@catenacyber catenacyber left a comment

Choose a reason for hiding this comment

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

Thanks for the work.

CI : ✅
Code : good
Commits segmentation : ok
Commit messages : ok
Git ID set : looks fine for me
CLA : you already contributed
Doc update : ok
Redmine ticket : ok, but this will not change that a DLT_RAW pcap captured on OpenBSD and read on Linux will print something wrong, right ?
Rustfmt : no rust
Tests : some nits in the SV PR, but mostly good
Dependencies added: none

@jlucovsky
Copy link
Contributor Author

Continued in #11670

@jlucovsky jlucovsky closed this Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

6 participants