Please see https://gitlab.com/wireshark/wireshark/-/merge_requests/9688
I have yet to port my (genuinely) local block type, but would like to see
if this approach looks OK.
More thought might be needed to stay safe while dealing with block types
that don't have options.
On Fri, Feb 3, 2023 at 11:01 AM Martin Mathieson <
martin.r.mathie...@googlemail.com> wrote:
>
>
> On Fri, Feb 3, 2023 at 7:25 AM Guy Harris <ghar...@sonic.net> wrote:
>
>> On Feb 1, 2023, at 12:58 AM, Joakim <oak...@gmail.com> wrote:
>>
>> > if you manage to add a dissector table that would be great! I believe
>> my company too will implement non-standard blocks so it would be very
>> convenient to have it available.
>>
>> Note that what's being discussed here would *only* handle dissecting the
>> non-standard blocks when you're dissecting the structure of the pcapng file
>> the same way that we can dissect the structure of, for example, JPEG files;
>> it won't affect the handling of the block in libwiretap nor will it affect
>> the handling of it in libwireshark when you're reading a pcapng file as a
>> capture file rather than as some type of file whose internal structure is
>> to be dissected.
>>
>>
> Yes, for me - for now, I only want to check the block values that get
> written into the pcapng file - another tool makes use of them.
>
>
>> We already have a plugin mechanism in libwiretap for the first of those
>> (although the interface could, I think, be improved; I'll look at some work
>> I did on that) and a plugin mechanism in libwireshark (currently using the
>> REC_TYPE_FT_SPECIFIC_{EVENT,REPORT} block type, but that might also be
>> improved).
>>
>> However, you might want to look at implementing *custom* blocks,
>> instead. If your company has a Private Enterprise Number:
>>
>> https://en.wikipedia.org/wiki/Private_Enterprise_Number
>>
>> it can use them, and would not have to worry about some other
>> organization using the same block number that you use.
>>
>
> We use 0x80000000 + <our-enterprise-number> for the first local block type
> we have.
> But we then also use the next 4 numbers for other private block types..
> I don't know if it was considered, but it would have been unnatural to
> squeeze our 5 block types into a single type.
>
>
>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
