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

fix(renderer): add more common protocols to protoname renderer #341

Merged
merged 6 commits into from
Aug 13, 2024

Conversation

DerInti
Copy link
Contributor

@DerInti DerInti commented Jul 29, 2024

As it yields an empty string in JSON output for "proto" (to which we rely heavily on):

  • add "unassigned", "experimental" and "reserved" to protoname renderer
  • add "GRE", "ESP" and "AH" to renderer

I refrained to add the whole IANA Protocol Numbers list due to reasons of usability and clarity.

…nassigned, experimental and reserved to protoname renderer
producer/proto/render.go Outdated Show resolved Hide resolved
producer/proto/render.go Outdated Show resolved Hide resolved
@marioschaefer
Copy link
Contributor

@lspgn what do you think?

40: "IL",
41: "IPv6",
42: "SDRP",
43: "IPv6-Route",
Copy link
Member

Choose a reason for hiding this comment

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

IPv6-EH-Routing maybe?

Copy link
Contributor

@marioschaefer marioschaefer Jul 31, 2024

Choose a reason for hiding this comment

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

IPv6-Route is the official IANA name, same as with ICMPv6 vs. IPv6-ICMP - we can deviate from the standard, as you like.
But in my opinion, we should stick to the standard.

--- update ---
commit was not planned, i thought i deleted my change request... will change again, according to your decision.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

+1 to sticking to official IANA protocol names

Copy link
Member

Choose a reason for hiding this comment

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

Good point

@lspgn
Copy link
Member

lspgn commented Jul 31, 2024

Looks good to me.
Thank you for the suggestion.

Just a small note:
The extended header for fragments will not be listed in the proto (it will replace with the proto from within this header if I'm not mistaken). In the future, with the support of SRv6 (#306) the behavior will likely be the same.

55: "Min-IPv4",
56: "TLSP",
57: "SKIP",
58: "IPv6-ICMP",
Copy link
Member

Choose a reason for hiding this comment

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

Would rather keep ICMPv6 since it's already being used

Copy link
Contributor

@marioschaefer marioschaefer Jul 31, 2024

Choose a reason for hiding this comment

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

Copy link
Member

@lspgn lspgn Aug 1, 2024

Choose a reason for hiding this comment

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

While I agree it's IANA, I would prefer not breaking existing implementations

Copy link
Contributor Author

Choose a reason for hiding this comment

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

my 2 cents:

  • I dont think we can mitigate the absence of information without some kind of breakage of existing implementations. As the Protocol Name is the only hint to the protocol field of the actually sampled packet (when utilizing JSON output) I'd prefer IANA names.
  • imho a viable alternative would be to add a field to the json output (proto_num?) with the int32 protonum - which would allow a clear mapping to official protocol names (for example in an enricher) and wont break existing implementations relying on the strings
    I'd keep all other protocols in protoName with their official names - with "ICMPv6" as only deviation.
    @lspgn @marioschaefer wdyt

Copy link
Contributor

Choose a reason for hiding this comment

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

@DerInti
point 1:
i'm on the complete same page

point 2:
I also thought about that and its probably the cleanest solution, bcs you have the number and the name.
But this will also break the existing implementation, since we will stick to the IANA-Names and the existing implementation doesn't use them.
on the other hand: how much longer do we want to carry the wrong name around with us. sooner or later it will be changed. the longer you wait, the more it hurts. that's why i'm a big fan of "sooner rather than later".

55: "Min-IPv4",
56: "TLSP",
57: "SKIP",
58: "IPv6-ICMP",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
58: "IPv6-ICMP",
58: "ICMPv6",

@marioschaefer
Copy link
Contributor

@lspgn whats the status on this PR?

@lspgn
Copy link
Member

lspgn commented Aug 11, 2024

@marioschaefer I'll do this shortly, was focused on #342 which has also some protocol naming I could adapt (6bfc106).
Since it's a large change already, I reconsidered not keeping icmpv6.

@lspgn lspgn merged commit 6f075d6 into netsampler:main Aug 13, 2024
1 check passed
@lspgn lspgn added the format New or existing formats (json, protobuf, etc.) label Aug 13, 2024
lspgn pushed a commit that referenced this pull request Aug 19, 2024
* fix(renderer): add more common protocols to protoname renderer, add unassigned, experimental and reserved to protoname renderer

---------

Co-authored-by: marioschaefer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
format New or existing formats (json, protobuf, etc.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants