Wireshark mailing list archives
Re: Does proto_deregister_field really work?
From: Paul Offord <Paul.Offord () advance7 com>
Date: Mon, 28 May 2018 17:12:16 +0000
Hi Richard, I have been working on a dissector that registers hfid each time a pcapng file is opened and deregisters them when the file is closed. I was having problems with reregistering but I think the problem was of my own doing. I'm still rewriting the code and I'll let you know if it all works as expected once I've finished. One hole I did fall down was not properly understanding precisely when various functions are called. For example, you might place the deregister in the cleanup() function. Trouble is cleanup() get's called on profile change. I'll watch your reports closely. Best regards...Paul Sent from Samsung Mobile on O2 -------- Original message -------- From: Richard Sharpe <realrichardsharpe () gmail com> Date: 28/05/2018 17:29 (GMT+00:00) To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] Does proto_deregister_field really work? On Sun, May 27, 2018 at 3:19 AM, Peter Wu <peter () lekensteyn nl> wrote:
Hi Richard, On Wed, May 09, 2018 at 04:51:13PM -0700, Richard Sharpe wrote:Hi folks, I have an application where I want to change the specification of an HF entry or two, and found proto_deregister_field. It would seem that I can deregister a field and then register a new version of it ... as long as I am careful. What is the cost of doing this? Is an alternative to register a fixed array but modify the entries?What was the use case for this dynamic field update? What property were you interested in? I am not sure how well dynamic field (de)registration is supposed to work. It is causing some memory leaks and I am worried that trying to solve those can result in other memory safety issues (use-after-free).
This is in relation to the radiotap headers for HE and HE-MU (and more). The issue is that there are fields in those headers that are unknown unless the appropriate known bit is set to true elsewhere in the header. The approach I took initially was to have two header types: 1. One for when the field was known, and 2. One for when the field was unknown where the search string had unknown in it I would then use the appropriate HF in the code. However, people have complained that this is weird. My thinking was: 1. I don't like it when fields are not dissected, and 2. By using a different search string when a field is unknown we would not get false positives (usually the field is 0, but 0 is usually also a valid value wen the field is known.) An alternative is to change the label associated with the field to include the word unknown, but I don't think you can have two HF fields with the same search string in them, so I wanted to explore dynamically changing hf structures. However, doing that now reintroduces the problem that searching on a field with the value 0 can result in false positives. -- Regards, Richard Sharpe (何以解�n?唯有杜康。--曹操)(传说杜康是酒的发明者) ___________________________________________________________________________ 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
Current thread:
- Does proto_deregister_field really work? Richard Sharpe (May 09)
- Re: Does proto_deregister_field really work? Peter Wu (May 27)
- Re: Does proto_deregister_field really work? Richard Sharpe (May 28)
- Re: Does proto_deregister_field really work? Paul Offord (May 28)
- Re: Does proto_deregister_field really work? Guy Harris (May 28)
- Re: Does proto_deregister_field really work? Richard Sharpe (May 28)
- Re: Does proto_deregister_field really work? Peter Wu (May 27)