Wireshark-bugs: [Wireshark-bugs] [Bug 8496] New: Lua doesn't provide all field values when there
| Bug ID |
8496
|
| Summary |
Lua doesn't provide all field values when there are multiple fields of the same abbrev
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.9.x (Experimental)
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
hadrielk@yahoo.com
|
Build Information:
--
When a Lua plugin tries to access a field from a packet, using the 'Field'
extractor class, wireshark will correctly push into Lua a FieldInfo object for
each instance of the Field type in the packet. If, however, there are multiple
field types with the same abbreviation, wireshark will push nil if the first
registered field type is empty for a given packet, even if the other field
type(s) of the same abbrev have values for the packet.
For example, download the sample pcap
'ansi_tcap_over_itu_sccp_over_mtp3_over_mtp2.pcap' from the wireshark sample
capture site, and load this Lua snippet:
local mymtp2tap = Listener.new(nil, "mtp2")
local mtp2_li_field = Field.new("mtp2.li")
function mymtp2tap.packet(pinfo, tvb)
local mtp2li_table = { mtp2_li_field() }
print ("number of found mtp2.li fields="..#mtp2li_table)
end
You will see this printed:"number of found mtp2.li fields=0"
Even though there is in fact an mtp2.li field in the capture's packet.
The reason is that there are *two* 'mtp2.li' field types registered by the
dissector: one for 8-bit encoding, one for 16-bit encoding. The 16-bit one is
registered second, and therefore ends up being first in the gpa_name_tree; so
when wslua goes to find the 'mtp2.li' field in lua_prime_all_fields() in
wslua_field.c, it'll get the 16-bit one. That's ok, but when it goes to
actually push the FieldInfo during run-time in Field__call(), the for-loop call
to proto_get_finfo_ptr_array() will get NULL because the 16-bit one isn't
populated for this packet. So it breaks out of the for-loop, and ends up not
pushing anything into Lua. Instead, it should have pushed the FieldInfo(s) for
any matching fields in the packet, and thus the 8-bit one.
The bug appears to not be Lua-specific, however. I think it's actually a bug
in proto_register_field_init(), for the handling of same_name_hfinfo. In that
if-statement, same_name_next_hfinfo will always be NULL, because the previous
hfinfo will not have had a same_name_next. So hfinfo->same_name_next will also
be set to NULL, meaning the newly added hfinfo field will not have a
same_name_next pointing to the just-replaced one. In fact, what ends up
happening is the new hfinfo ends up pointing backwards to the just-replaced one
- ie., the just-replaced one is the same_name_prev of the new one, even though
the new one will be the root hfinfo in the gtree. In other words, the
linked-list is backwards... was it meant to be that way?
You would think such a thing would cause other failures - for example a display
filter should fail. But it turns out the display fiter compiler walks
backwards up the linked list looking for the first one, so it works. See
dfw_append_read_tree() in gencode.c.
So... the question is should wslua_field.c be changed to accomodate this model,
or should proto_register_field_init() be changed? I'm hesitant to change
proto_register_field_init(), because there are a LOT of duplicate hfinfo's
(approximately 13,760 of them!).
You are receiving this mail because:
- You are watching all bug changes.
