On Mar 18, 2013, at 8:14 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> 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
