On Nov 27, 2016, at 1:19 AM, Helge Kruse <Helge.Kruse@xxxxxxx> wrote:
> I'm writing a dissector in LUA. The protocol has a packet consisting of
> a wide character string. For this purpose I added an appropriate header
> field to the dissector:
>
> local f_fsWFileName = ProtoField.new ("WFileName", \
> "KITL.PPSH.WFileName", ftypes.UINT_STRING, nil, base.NONE)
>
> and added it to the protocol:
>
> proto_ppsh.fields = { f_fsWFileName }
>
>
> This results in an error:
>
> Lua: Error during loading:
> [string "C:\Users\Helge\AppData\Roaming\Wireshark\plug..."]:131: bad
> argument #3 to 'new' (ProtoField_new: Invalid ProtoField field type)
>
> This is strange, because I checked that the type UINT_STRING is defined
> in "C:\Program Files\Wireshark2\init.lua":
>
> ftypes = {
> ....
> ["UINT_STRING"] = 27,
> ....
> }
Unfortunately, "defined" and "supported" aren't the same.
In the Wireshark source code for creating a new ProtoField, the code that checks the field type is:
...
/* TODO: new in 1.99 and not handled yet */
case FT_UINT40:
case FT_UINT48:
case FT_UINT56:
case FT_INT40:
case FT_INT48:
case FT_INT56:
/* older but not supported yet (or maybe ever) */
case FT_UINT_STRING:
case FT_PCRE:
case FT_AX25:
case FT_STRINGZPAD:
default:
WSLUA_ARG_ERROR(ProtoField_new,TYPE,"Invalid ProtoField field type");
break;
so, in fact, UINT_STRING isn't supported as a type in Lua dissectors.
The error message is bogus - it should say "Unsupported" for all the cases except for "default" and FT_PCRE, and only say "Invalid" for "default" and FT_PCRE (FT_PCRE is an internal type for use by the code that implements Perl-compatible regular expression matching for packet or field data; it's not a valid type for fields in packets).
So you'd either have to fetch the length yourself and use an FT_STRING field, or get FT_UINT_STRING supported in Lua.
