On Mar 18, 2013, at 8:14 AM, Hadriel Kaplan <[email protected]> wrote:
> So apparently I'm wrong... well, sorta wrong - there are two 'mtp2.li' fields > as I said, but it appears that the Lua code will unfortunately return nil if > the "first" one is not filled in, and the "first" one in this case happens to > be the second 'mtp2.li' field, namely the 16-bit extended annex-a one. I had > assumed the second field of the same name would be second in the lookup tree, > but apparently it replaces the previous one's spot and the previous one gets > attached to it, so effectively the 16-bit mtp2.li field is the first one > found. Since your packets aren't annex-a, that mtp2.li field is empty, and > the code pushes back a nil into Lua. > > ISTM that's a bug. The code should walk through all fields of the same name, > and push back the values of any it finds populated, into Lua. Bug 8496 submitted. The fix depends on whether the odd behavior of proto.c::proto_register_field_init() in how it handles duplicate hfinfo's was intentional or not. It seems counter-intuitive to me to build the hfinfo linked-list backwards relative to the root hfinfo in the gtree; but if the only code having an issue with it is the wslua code, then it might be safer to just fix the wslua code to walk backwards along the linked-list instead of forwards. -hadriel ___________________________________________________________________________ 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
