Interesting results! If I edit cf_select_packet (in file.c) and add a call to tap_queue_init(cf->edt) just before the call to epan_dissect_run, it fixes my problem.
tap_queue_init calls epan_dissect_prime_dfilter on each item in the tap_listener_queue, which sets the ref_count for those fields to DIRECT. This means that calls to proto_item_add_<whatever> will also add the field to the interesting_hfids hash table, where they are later found by my Lua postdissector via Field__call. What I *don't* know is whether this is actually a reasonable strategy for solving the original problem (described in subject of post). After only three days of digging through the source code, I definitely do not qualify as a Wireshark expert, just a lucky beachcomber who happened to find two shells that seem to fit together. Can anyone comment on this? Thanks, b.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
