[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

Have changed the file name (compromise: file-pcapng-darwin.c).

There are some Darwin-related options for the Enhanced Packet Block type, that I didn't try to move to file-pcapng-darwin.c.  Is it likely to be common for local packet block definitions to also have options for Enhanced Packet Block (or any other standard blocks)?

Martin

On Sat, Feb 4, 2023 at 5:15 PM Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:

Yes, if there are likely no other similar types. 

On Sat, 4 Feb 2023, 16:56 chuck c, <bubbasnmp@xxxxxxxxx> wrote:

file-pcapng_darwin_process_event.c

I guess it's not as bad as the filenames with a "+" in the names, but would file-darwin.c be enough?

On Sat, Feb 4, 2023 at 10:48 AM Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

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.mathieson@xxxxxxxxxxxxxx> wrote:

On Fri, Feb 3, 2023 at 7:25 AM Guy Harris <gharris@xxxxxxxxx> wrote:

On Feb 1, 2023, at 12:58 AM, Joakim <oakimk@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe