Re: New pcap-ng block requires a rescan

[Anders Broman <a.broman58 () gmail com>]

FWIW I think packet-diameter register it's fields when the first diameter
packet is encountered.

2018-06-08 15:00 GMT+02:00 Paul Offord <Paul.Offord () advance7 com>:

> I’m now able to update this.  Unfortunately, Chris’s suggestion isn’t the
> cause of my problem.  The explanation of the issue is as follows:
>
>
>
> As described below, I’m writing a dissector that handles two new block
> types:
>
>
>
>    - Text Descriptor Block (TDB) that carries field definitions -
>    basically serialised hfinfo values
>    - Text Record Block (TRB) that carries data defined by the field
>    definitions in the TDB
>
>
>
> The TDB is “internal” and so isn’t rendered in the packet list (like an
> IDB).  Each TRB results in a frame in the packet list.
>
>
>
> Normally, protocol fields are registered through a
> proto_register_field_array() call inside proto_register_XXX(void).
> However, registering the fields in proto_register_XXX(void) is too early
> for my dissector as it doesn’t get the field definitions until it has read
> the TDB.  Therefore, it registers the fields in the tdb_read_block()
> function.
>
>
>
> As described below, the problem I have is that packet list column data is
> not rendered when a file is opened, even though the protocol tree in the
> detail window looks fine.  I tried a test by moving one field registration
> from the TDB block read function to proto_register_XXX(void) and that field
> gets rendered in the packet list correctly.
>
>
>
> My questions are:
>
>
>
>    - Is this a bug?
>    - Can you only register hfs in proto_register_XXX(void)?
>
>
>
> Any guidance would be much appreciated.
>
>
>
> Best regards…Paul
>
>
>
> *From:* Paul Offord
> *Sent:* 08 April 2018 22:57
>
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* Re: [Wireshark-dev] New pcap-ng block requires a rescan
>
>
>
> Thanks Chris.  I haven't fixed it and that's a good suggestion.
>
>
>
>
>
>
>
> Sent from Samsung Mobile on O2
>
>
>
>
>
> -------- Original message --------
>
> From: "Maynard, Chris" <Christopher.Maynard () IGT com>
>
> Date: 08/04/2018 17:10 (GMT+00:00)
>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
>
> Subject: Re: [Wireshark-dev] New pcap-ng block requires a rescan
>
>
>
> Hi Paul,
>
> I’m not sure if you’ve found a solution for this yet or not, but in case
> you haven’t, one thing that comes to mind is to remove an “if (tree)”
> checks you might have, as columns may need to be populated whether the tree
> is NULL or not.
>
> - Chris
>
>
>
> *From:* Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org
> <wireshark-dev-bounces () wireshark org>] *On Behalf Of *Paul Offord
> *Sent:* Wednesday, April 4, 2018 6:21 AM
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* [Wireshark-dev] New pcap-ng block requires a rescan
>
>
>
> Hi,
>
>
>
> I’ve reached a milestone with the TRB support; all basic Wireshark
> functionality is complete.  There is a remaining problem.  On opening a
> file, the blocks are decoded (see the protocol tree in the following
> screenshot) but the values are not rendered in the Packet List columns.
>
>
>
>
>
> If I force a rescan (typically by changing to another profile and then
> back to the original profile), the column values are rendered.
>
>
>
>
>
> I don’t think this is a problem with the TRB dissector.  I have tried
> figuring out what might be causing this problem, but I must admit I am
> struggling to understand how the column values are rendered.
>
>
>
> Can someone give me a steer?  What areas should I be looking at?  How
> should I debug this problem?
>
>
>
> Any help would be much appreciated.
>
>
>
> Best 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
> ______________________________________________________________________
>
> CONFIDENTIALITY NOTICE: This message is the property of International Game
> Technology PLC and/or its subsidiaries and may contain proprietary,
> confidential or trade secret information.  This message is intended solely
> for the use of the addressee.  If you are not the intended recipient and
> have received this message in error, please delete this message from your
> system. Any unauthorized reading, distribution, copying, or other use of
> this message or its attachments is strictly prohibited.
>
> ______________________________________________________________________
>
> 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