I thought I’d figured this out, then it turns out I hadn’t but now I think I have – are you still following? The first thing I have realised is that the epan dissectors only generate displayable and filterable values (tcp.len, smb2.msg_id,
etc.) if a tree is passed to them and the only place these values get saved is in the tree. Normally Wireshark does not create a tree on the 1st scan of a trace file. However, if a tap is registered it can/is registered with a display filter and
the Wireshark code ( specifically cf_read() ) checks for filtering taps and sets a gboolean ( create_proto_tree ) accordingly: create_proto_tree = (dfcode != NULL || have_filtering_tap_listeners() || (tap_flags & TL_REQUIRES_PROTO_TREE)); Later this Boolean is used as a switch in: epan_dissect_init(&edt, cf->epan, create_proto_tree, FALSE); The edt then has an associated tree ( edt->tree ), and the dissectors are then called with the tree. The reason MATE and LUA dissectors have access to the field values during the 1st scan is because they both register filtering
tap listeners. So that’s what I’m going to try in TRANSUM. From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Paul Offord I’ve made some progress. I traced MATE and looked at how it registers its post-dissector. I now get a tree on the 1st
scan. I’ll write up some notes on C post-dissectors when I get something that works. Best regards…Paul From:
wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Paul Offord I've hit a problem. WS scans the trace file twice. I need access to protocol fields (e.g. tcp.len and smb2.ses_id) during the first scan. Unfortunately with the C postdissector the tree value passed during the first scan is NULL. During the second scan I do get the tree. I guess the LUA code uses the proto_tree_prime_hfid()
outlined below. Any suggestions how I move forward gratefully accepted. Sent from Samsung Mobile on O2 -------- Original message -------- From: Guy Harris Date:05/09/2016 03:59 (GMT+00:00) To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Extracting field values in a C post-dissector
On Aug 22, 2016, at 6:40 AM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:
______________________________________________________________________ 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 ______________________________________________________________________ |
- References:
- Re: [Wireshark-dev] Extracting field values in a C post-dissector
- From: Paul Offord
- Re: [Wireshark-dev] Extracting field values in a C post-dissector
- From: Paul Offord
- Re: [Wireshark-dev] Extracting field values in a C post-dissector
- Prev by Date: Re: [Wireshark-dev] Enable extcap by default or not
- Next by Date: Re: [Wireshark-dev] Enable extcap by default or not
- Previous by thread: Re: [Wireshark-dev] Extracting field values in a C post-dissector
- Next by thread: [Wireshark-dev] Remove of GTK interface
- Index(es):