Hi Pascal,
The use of proto_registrar_get_id_byname() looked good but there’s a problem. It’s declared in proto.h as:
extern int proto_registrar_get_id_byname(const char *field_name);
I think this means that it’s not exported for use by plugin DLLs; it would need to be defined like this:
WS_DLL_PUBLIC int proto_registrar_get_id_byname(const char *field_name);
Or am I missing something?
Best regards…Paul
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Pascal Quantin
Sent: 22 August 2016 14:40
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Extracting field values in a C post-dissector
Hi Paul,
2016-08-22 11:57 GMT+02:00 Paul Offord <Paul.Offord@xxxxxxxxxxxx>:
I’m struggling a bit here. Can someone give me a pointer to the code that shows me how LUA extracts
dissected protocol values?
By having a quick look at the code, I *think* you will want first to retrieve the hfindex of a given field by using proto_registrar_get_id_byname(), then mark it as "interesting" with proto_tree_prime_hfid()
and then once dissection is done call proto_get_finfo_ptr_array() to retrieve an array of the values for a given tree (you can go back to the root tree with proto_tree_get_root()). Or a cll to proto_find_finfo() should work also without the need to prime the
field, but should be slower according to the comments in proto.h.
Worth testing it and giving your findings as I have never tried them myself. I hope I gave you valid hints :) Fingers crossed.
Thanks and regards…Paul
From: Paul
Offord
Sent: 06 June 2016 10:42
To: 'Developer support list for Wireshark' <wireshark-dev@xxxxxxxxxxxxx>
Subject: RE: [Wireshark-dev] Extracting field values in a C post-dissector
No problem. I’ll take a look at the code as you suggest.
From:
wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Graham Bloice
Sent: 03 June 2016 12:34
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Extracting field values in a C post-dissector
On 3 June 2016 at 12:04, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
Hi Graham,
My post-dissector should run after all other dissectors have completed. The reference to tcp.len is
just an example. I need access to the full stack e.g. everything from ethertype to SMB msg id. I purposely don’t want to do any protocol dissection myself.
I guess that what I am effectively asking for is access to everything in the dissector tree.
Thanks for the pointer to README.dissector – I have written a C dissector before, goodness knows why
I had forgotten this doc L I’ve scanned through it but it doesn’t seem to cover my issue.
Best regards…Paul
Ah, sorry Paul I skipped over the phrase "post-dissector". Those are a bit of an odd fish, I suggest you have a look at how the Lua field extractor interface is defined in the
C code.
From:
wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Graham Bloice
Sent: 03 June 2016 09:16
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Extracting field values in a C post-dissector
On 3 June 2016 at 08:47, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
I want to rewrite a LUA post-dissector in C. How can my code get dissected data values, e.g. tcp.len, into a C variable? In LUA you define a field extractor. Is there an equivalent
in C?
I’ve looked at the wiki and I’ve looked at the MATE code but I haven’t found how to do it.
Thanks and regards…Paul
doc\README.dissector is your guide for C-based dissectors.
Are you aiming to get values from dissectors called before yours, e.g. your protocol runs on tcp, so tcp dissection is done first, then the data from the tcp segment is handed to
your dissector?
If so, then the pinfo structure passed to your dissector has a lot of info about previous dissection, see epan\packet_info.h for the structure members.
Is your reference to tcp.len just a general example or an actual value you *think* you need? Generally in tcp based dissectors, the length of any individual tcp segment is immaterial,
you just process the data handed to your dissector in the *tvb. This is especially the case when a protocol PDU can either be spread over multiple tcp segments, or multiple PDU's in a single segment. This is where tcp reassembly/desegmentation is used.
--
--
______________________________________________________________________
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://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
______________________________________________________________________
|
