You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
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.
The text was updated successfully, but these errors were encountered: