Re: Adding support for a new PCAP-NG block

[Roland Knall <rknall () gmail com>]

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 there in packet_info and call it from your original dissector.

And no, there is no documentation as of yet.

I would just start to write a dissector for the block only. If you have
that, I would start a discussion about data storage from there.

regards
Roland

On Wed, Jan 17, 2018 at 1:47 PM, Paul Offord <Paul.Offord () advance7 com>
wrote:

> 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 add support for new
> block types.  I did a check on code that refers to this function and found
> that nothing uses it at the moment.
>
>
>
> So my questions are:
>
>
>
>    - Should I modify pcapng_open or use wtap_opttype_register_custom_
>    block_type?
>    - If the latter, is there any documentation, or even just an
>    explanation of wtap_opttype_register_custom_block_type and how to use
>    it?
>    - I will need to save interpreted data from the new TSDBs somewhere
>    that will later be accessible to dissectors.  Which structure should I use?
>
>
>
> Thanks and regards…Paul
>
>
>
>
>
> *From:* Paul Offord
> *Sent:* 03 November 2017 16:41
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* RE: [Wireshark-dev] Capture filename not available at plugin
> init time
>
>
>
> So the plan would be:
>
>
>
>    - Add support to read the TSDB and create the resulting structures
>    - Add support to read Text Record Blocks (TRBs)
>       - This is mostly stuff that Guy Harris described a while back
>       - In my current code the data records are encapsulated in a dummy
>       Ethernet frame
>    - Add support to mergecap to correctly handle the TSDBs
>       - Similar to adjusting IDBs when files are merged
>    - Add the dumpcap code to read text files and produce pcap-ng
>
>
>
> I think I’ll leave this idea to circulate for a few days before I start
> writing code.  Maybe I’ll pester the developers next week at SF EU.
>
>
>
> I will also see if there is an easy way to get plugin_if_get_ws_info to
> work in the init routine as I still believe this will be useful to
> dissector developers.
>
>
>
> Thanks and regards…Paul
>
>
>
> *From:* Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org
> <wireshark-dev-bounces () wireshark org>] *On Behalf Of *Roland Knall
> *Sent:* 03 November 2017 16:24
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* Re: [Wireshark-dev] Capture filename not available at plugin
> init time
>
>
>
> This is a different thing here. If TSDB is a common code block, I think
> the chances are really good.
>
>
>
> But still it needs the basic read functionality in dumpcap
>
>
>
> cheers
>
>
>
> On Fri, Nov 3, 2017 at 5:18 PM, Paul Offord <Paul.Offord () advance7 com>
> wrote:
>
> OK – I understand.
>
>
>
> If I write the code to read the TSDB and make it available do you think it
> would be accepted into the main project?  I’m thinking about my syncro
> experience here.
>
>
>
> Thanks and regards…Paul
>
>
>
> *From:* Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org] *On
> Behalf Of *Roland Knall
> *Sent:* 03 November 2017 14:15
>
>
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* Re: [Wireshark-dev] Capture filename not available at plugin
> init time
>
>
>
> Hi Paul
>
>
>
> You should never assume, that you will be able to read the file, while WS
> is reading it. If this is working right now, it might be out of pure
> coincidence, that said, the real thing here should be to get dumpcap to use
> pcapng as input format, which would give you the tsdb block where you need
> it to be, during dissection.
>
>
>
> The support for any pcap-ng extension block is already in Wireshark. The
> issue still is, to get the block structure through.
>
>
>
> cheers
>
> Roland
>
>
>
> On Fri, Nov 3, 2017 at 3:07 PM, Paul Offord <Paul.Offord () advance7 com>
> wrote:
>
> Thanks for responding Roland.
>
>
>
> I’ve written a tool that reads a log file and converts it to a PCAP-NG
> with a matching dissector.  The pcap file carries a data descriptor block
> in a new PCAP-NG block type called as TSDB.  The TSDB carries the
> information needed to register the header fields.  To add support for the
> TSDB into core Wireshark is going to be a big job (which I will submit
> later).  As a quick solution, the dissector gets the information by
> directly opening and reading it from the PCAP-NG file – hence the need for
> the filename.
>
>
>
> The above aside, and I can guess you are thinking I’m just trying to avoid
> a bigger coding job, it’s not unreasonable to expect plugin_if_get_ws_info
> to get the filename at init time, and init is called when the filename is
> known.
>
>
>
> I have a really kludgie workaround which is to read the TSDB and register
> the hf structure on the first call to the dissector, but it’s not ideal.
>
>
>
> Best regards…Paul
>
>
>
> *From:* Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org] *On
> Behalf Of *Roland Knall
> *Sent:* 03 November 2017 13:53
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* Re: [Wireshark-dev] Capture filename not available at plugin
> init time
>
>
>
> Hi Paul
>
>
>
> As far as I know, cf_open can still fail after calling the init-functions.
> In that case you would get the filename, but the capture is already closed.
>
>
>
> My question is, why do you need the filename in the first place?
>
>
>
> Also, you could set the filename at a later point. If you implement a
> tap-interface, you could set the filename in the first tap-print callback.
> Makes sense, 'cause you normally only have data at this point anyway.
>
>
>
> You can raise this as an improvement (do not think it is a bug) if you
> want to, not really sure though, if it should be changed
>
>
>
> cheers
>
>
>
>
>
> On Fri, Nov 3, 2017 at 2:49 PM, Paul Offord <Paul.Offord () advance7 com>
> wrote:
>
> I have a dissector that needs the capture file name at the time my
> dissector’s init function is called.  I attempt to get the name with
> plugin_if_get_ws_info(…), not an unreasonable request I think you’ll agree,
> but unfortunately the filename comes back as a NULL pointer.
>
>
>
> I’ve traced through the code and this is what happens:
>
>
>
>    - We pass through the MainWindow signal and slot stuff and eventually
>    call cf_open(…) in file.c with the filename as one of the parameters
>    - cf_open(…) opens the file to test the validity of the filename and
>    then closes with cf_close(cf)
>    - cf_close(cf) frees the memory holding the filename and NULLs the
>    filename pointer in the cf structure
>    - cf_open then creates a new epan session with ws_epan_new(cf)
>    - ws_epan_new(cf) calls epan_new() which calls init_dissection() and
>    this is where eventually my dissector’s init function gets called
>    - My dissector calls plugin_if_get_ws_info(…) which attempts to get
>    the filename info from the cf structure, which due to the above returns a
>    NULL filename pointer
>    - Eventually we return back to cf_open(…) and a little later we set up
>    the file name in the cf structure – all too late for my dissector’s init
>    function
>
>
>
> So my questions are:
>
>
>
>    - Can I raise this as a bug?
>    - If not, would a solution that made the filename available to
>    plugin_if_get_ws_info(…) at init time be accepted?
>    - What would be an acceptable solution?
>
>
>
> Thanks and regards…Paul
>
>
> ______________________________________________________________________
>
> 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
> ______________________________________________________________________
>
>
> ____________________________________________________________
> _______________
> 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-request () wireshark org?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
> ______________________________________________________________________
>
>
> ____________________________________________________________
> _______________
> 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-request () wireshark org?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
> ______________________________________________________________________
>
>
> ____________________________________________________________
> _______________
> 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-request () wireshark org?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
> ______________________________________________________________________
>
> ____________________________________________________________
> _______________
> 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-request () 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-request () wireshark org?subject=unsubscribe