OK - thanks.
I'm in this deep and so I guess I'm up for the challenge. I'll create a list of the things I need to do and then circulate for comment. I'll try to break into small incremental code changes.
@realrichardsharpe I think this may answer your question about reregistering hfs.
Best regards...Paul
-----Original Message-----
From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Guy Harris
Sent: 08 June 2018 18:36
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] New pcap-ng block requires a rescan
On Jun 8, 2018, at 10:10 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
> proto_register_diameter(void) contains:
>
> /* Delay registration of Diameter fields */
> proto_register_prefix("diameter", register_diameter_fields);
>
> I wasn’t aware of this function.
It might not help in your case.
What it *does* support is "lazy" registration of fields, where the field registration is delayed until a field with a given prefix needs to be used (e.g., in a custom column or in a packet-matching expression). The callback specified as the second argument to proto_register_prefix() is called in that case.
This lets you use Diameter fields in custom columns, read filters, and coloring rules.
This works for Diameter because the only reason to delay registering Diameter fields is that it's time-consuming - it has to read the entire Diameter dictionary and process it.
In your case, where the file *itself* contains information that's used to define fields, there's no callback you can supply.
In order to allow your fields to be used in custom columns, read filters, and coloring rules, you will have to
1) require that *all* TDBs in a pcapng file section appear before *any* block type that *might* (not *will*, but *might*), have a custom column, be affected by a coloring rule, be filtered by a display filter, or be discarded by a read filter - this presumably includes all packet blocks and TRBs;
2) arrange that there be a phase in the capture-file reading process that comes *after* the file is opened but *before* the main record-reading loop occurs, and *before* the custom columns, read filter, and coloring rules are used.
This will require a significant API change in libwiretap and significant changes to the file reading process in programs that use it, so this will only work in Wireshark 3.0.
___________________________________________________________________________
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
______________________________________________________________________
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
