|
I have a dissector for a protocol sending packets containing ASCII strings of a delimited format over a TCP stream.
/AREA/NAME/FILLED/GREEN/1/2000/4000//
Sometimes the values are floating point, like
/ENV/-/-/1.0/90.0/100.0/-/-/-/5000.0//
I'm dissecting the format ok, but I can't use unit_name_string for these FT_STRING defined header fields.
I see (in 2.4.1) that unit_name_string is disabled for FT_STRING (tmp_fld_check_assert is not allowing hfinfo->strings), so I've been using proto_tree_add_string_format..., but wondering if there's potential to allow FT_STRING to use unit_name_string.
One could classify the string contents as an integer or floating point value to pass to one of these functions:
unit_name_string_get_value
unit_name_string_get_value64
unit_name_string_get_double
If the string is not a valid number, or out of range, I'm not sure what the proper error behavior should be. Could be to ignore the 'strings' value, throw an assert, or malformed packet. It's possible that a value is missing '-' but I wouldn't want it
to mark the packet as bogus because of it.
Mostly, it'd be easier putting the units in the header field definition instead of having a separate table of header field -> unit_name_string for these FT_STRING types and doing the checking/formatting myself.
Does this idea seem compatible with proto.c?
Thanks,
John Dill
| 
