Wireshark · Wireshark-dev: Re: [Wireshark-dev] Does proto_deregister_field really work?

[Paul Offord <Paul.Offord@xxxxxxxxxxxx>]

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@xxxxxxxxx>

Date: 28/05/2018 17:29 (GMT+00:00)

To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

Subject: Re: [Wireshark-dev] Does proto_deregister_field really work?

On Sun, May 27, 2018 at 3:19 AM, Peter Wu <peter@xxxxxxxxxxxxx> 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@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
______________________________________________________________________