Re: [Wireshark-dev] Adding support for a new PCAP-NG block

Hi Yes you should use the wtap_opttype_register_custom_block_type structure. In theory, the data from the block get's stored inside the necessary wtap structures and can later be accessible via packet_info if I remember correctly. Or you could also write a separate dissector, store the data from

Re: [Wireshark-dev] Adding support for a new PCAP-NG block

Hi Roland. Does that mean that from within a dissector I could: * Register the new block type * Get access to the new block data from the dissector Basically, can I do everything from a new dissector and not touch Wireshark core code? Thanks and regards…Paul From: Wireshark-dev

Re: [Wireshark-dev] 2.5.0 release on January 16

On Wed, Jan 17, 2018 at 2:05 AM, Gerald Combs wrote: > On 1/13/18 4:16 AM, Stig Bjørlykke wrote: >> - Qt: Missing string translations after source code was moved to >> utils/models/manager/widgets subdirectories > > Do you know what's missing? This shouldn't be too hard to

Re: [Wireshark-dev] 2.5.0 release on January 16

On Wed, Jan 17, 2018 at 1:39 PM, Anders Broman wrote: > > > -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On > Behalf Of Gerald Combs > Sent: den 17 januari 2018 02:05 > To: Developer support list for Wireshark

Re: [Wireshark-dev] 2.5.0 release on January 16

-Original Message- From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Gerald Combs Sent: den 17 januari 2018 02:05 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] 2.5.0 release on January 16 On 1/13/18 4:16

[Wireshark-dev] Adding support for a new PCAP-NG block

I want to make a start on the plan below. Last night I took a look at the relevant code. I started by adding support for TSDBs into the function pcapng_open(…) in pcapng.c but I then stumbled across wtap_opttype_register_custom_block_type(…) in wtap_opttypes.c which seems to be a framework to