https://gitlab.com/wireshark/wireshark/-/merge_requests/9688 has been merged.
On Sat, Feb 4, 2023 at 11:11 PM Martin Mathieson < martin.r.mathie...@googlemail.com> wrote: > 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.mathie...@googlemail.com> wrote: > >> Yes, if there are likely no other similar types. >> >> On Sat, 4 Feb 2023, 16:56 chuck c, <bubbas...@gmail.com> 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@wireshark.org> 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.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 >>>> >>> >>> ___________________________________________________________________________ >>> 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
