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

Custom link-layer types, similar to custom blocks and options#52

Open
guyharris opened this issue Aug 10, 2018 · 1 comment
Open

Custom link-layer types, similar to custom blocks and options #52

guyharris opened this issue Aug 10, 2018 · 1 comment

Comments

@guyharris
Copy link
Collaborator

There's at least one pcapng user who wants to be able to support proprietary fieldbus protocols in their captures but don't want to register them as official link-layer header types (apparently, that might involve revealing the names of the protocols, and the protocols are so proprietary that even that's not acceptable).

And some vendors have their own protocols and resell equipment from vendors who have other such protocols, so they can't all be assigned, for example, LINKTYPE_USER1.

I can see others wanting to have proprietary unregistered protocols and give them an identifier guaranteed to be unique.

So perhaps we should support custom link-layer types, identified, like custom blocks and options, by a Private Enterprise Number and a per-enterprise identifier.

A couple of ways of implementing this are:

  1. Reserve a LinkType value of 0xFFFF in an IDB for custom link-layer types, and require an IDB with that link-layer type to have a new "custom link-layer type" option, containing a PEN and a 32-bit per-enterprise identifier.

  2. Add a new "Custom Interface Description Block" (name subject to revision if that's a stupid name), with most of the same fields, and all of the same options, as an IDB, but with the LinkType and Reserved fields replaced by a PEN and a 32-bit per-enterprise identifier.

@packetfoo
Copy link
Contributor

Both implementations are good ways to do this ("Custom IDB" sounds good, maybe "Private IDB" would work, too), but if I'd have to choose I'd slightly favor implementation 1 if only to keep the numbers of different block types small. But I'm also not against implementation 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants