[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6020

James Harvey <james.harvey@xxxxxxxxxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |james.harvey@thales-esecuri
                   |                            |ty.com

--- Comment #14 from James Harvey <james.harvey@xxxxxxxxxxxxxxxxxxxx> 2011-07-22 09:25:58 PDT ---
I can reproduce this bug in my environment also, with a Wireshark 1.6.1
built from source. I do not recall seeing this bug with previous versions
of Wireshark. I've not tried building a bleeding-edge version to check the
bug still exists in more recent versions. 

We have a custom in-house network protocol I've written a Lua dissector
for; it post-dissects SSL traffic (as it happens it's all unencrypted SSL
so the decryption is a no-op). The Lua post-dissector tries to set the
values of the Protocol and Info columns to something more interesting than
'TLS 1.2' and 'Application Data' respectively. 

However, if you load a packet trace into Wireshark, these two columns are
often not set correctly (even though the rest of the custom dissection
correctly adds interesting bits to the packet details table). It seems
pretty random whether or not the Lua code gets to set them -- and, quite
often, if you reload the packet display, the set of columns that are
correctly set by the Lua code changes. 

Loading the same packet trace into tshark reliably sets the columns to the
correct (Lua-generated) values each time. 

I haven't any example code to add, mainly because the attachments here
mimic my setup almost exactly. 

I've had no experience with the Wireshark code before now but I've been
looking at a test trace in the debugger. I have a trace of a single packet,
which correctly sets the column headings (from Lua) when _loaded_, but if
you then reload the display will reset the columns to the values set by the
SSL dissector (bypassing the Lua code). Hopefully this may be useful to
someone who knows the code better than me. 

The problem in a nutshell is that the Lua code is not consistently called
with the column info struct present: when pinfo->cinfo is NULL the Lua code
silently fails to update the column data. 

When the trace file is loaded epan_dissect_run() (which ultimately calls
into the Lua code) is called three times:

- once from add_packet_to_packet_list(), which only sets the column info if
   the tap_flags includes TL_REQUIRES_COLUMNS, which is unset here. 

- once from cf_select_packet(), which hard-codes cinfo to NULL (with a
   comment saying 'We don't need the columns here'). 

- once from packet_list_dissect_and_cache_record(), which is called with
   dissect_columns=1 and so _does_ create and supply the column info
   struct. 

It's the third of these calls which enables the Lua dissector to correctly
modify the column information. 

However, when View->Reload is selected, epan_dissect_run() is only called
twice:

- once from add_packet_to_packet_list() (as above)
- once from cf_select_packet() (as above)

The Lua code is never supplied with the column info struct, in this case,
so it never successfully sets the column info. 

I'm out of time on this for now, and I've not tried to debug tshark loading
the same packet trace. Hopefully this info is useful, in any case, and
let me know if there's anything else I could do to debug. Sadly it's
unlikely I'll be able to send specific sample code in because it's an
unreleased commercial product that I'm testing.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.