Thanks Anders.
proto_register_diameter(void) contains:
/* Delay registration of Diameter fields */
proto_register_prefix("diameter", register_diameter_fields);
I wasn’t aware of this function. I’ll need to investigate. The code in packet-diameter is quite dense and so it may take me some time to understand it.
Change 14711 (
https://code.wireshark.org/review/14711 ) refers to doc for proto_register_prefix(). Is there any, and where can I find it? It’s not in dissector.README.
Thanks and regards…Paul
From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx>
On Behalf Of Anders Broman
Sent: 08 June 2018 14:25
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] New pcap-ng block requires a rescan
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@xxxxxxxxxxxx>:
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@xxxxxxxxxxxxx>
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 --------
Date: 08/04/2018 17:10 (GMT+00:00)
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
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@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
______________________________________________________________________
|