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 <[email protected]> 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 <[email protected]> > *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:[email protected] > <[email protected]>] *On Behalf Of *Roland Knall > *Sent:* 03 November 2017 16:24 > *To:* Developer support list for Wireshark <[email protected]> > *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 <[email protected]> > 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:[email protected]] *On > Behalf Of *Roland Knall > *Sent:* 03 November 2017 14:15 > > > *To:* Developer support list for Wireshark <[email protected]> > *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 <[email protected]> > 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:[email protected]] *On > Behalf Of *Roland Knall > *Sent:* 03 November 2017 13:53 > *To:* Developer support list for Wireshark <[email protected]> > *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 <[email protected]> > 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
