This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Is there a Lua bug that prevents byte highlighting upon field selection?

1

The following Lua does not highlight the corresponding bytes upon field selection (for f_length):

version = "0.1";
workPort = 3003; 
full_name = "Service Control Point protocol";
short_name = "SCP";
perent_port = "tcp.port";
SCP_proto = Proto(short_name,full_name);
local f_length = ProtoField.uint32("length", "length");
SCP_proto.fields = {
    f_length
    }
function SCP_proto.dissector (buf, pkt, root)
    pkt.cols.protocol = SCP_proto.name
    subtree = root:add(SCP_proto, buf(0));
    subtree:append_text("(using BER),version "..version.." by SMT-ICC");
local length = subtree:add(f_length,buf(0,4):le_uint() );

end

function SCP_proto.init() end

local tcp_dissector_table = DissectorTable.get(perent_port) dissector = tcp_dissector_table:get_dissector(workPort) tcp_dissector_table:add(workPort, SCP_proto)

…but this does:

function SCP_proto.dissector (buf, pkt, root)
…
local length = subtree:add(f_length,buf(0,4));
local length_v = buf(0,4):le_uint();
length:set_text("length:\t" .. length_v)
end

Is this a Wireshark 1.7.x bug or a problem with my code above?

asked 08 Jun ‘12, 01:54

PavelMSTU's gravatar image

PavelMSTU
26236
accept rate: 50%

edited 08 Jun ‘12, 03:20

helloworld's gravatar image

helloworld
3.1k42041


One Answer:

4

This is not a Wireshark bug. You just happen to be exercising one of the features of TreeItem.add().

TreeItem.add() takes a ProtoField and a TvbRange as parameters. The ProtoField specifies the field's label and the format of the raw data (among other things). The TvbRange contains the raw data to be parsed. Given the ProtoField and the TvbRange, the TreeItem knows how to parse the raw data, adding the labeled value to the protocol tree and highlighting the bytes that correspond to the TvbRange upon field selection.

However, the TvbRange parameter in TreeItem.add() is optional. The TreeItem will happily take a literal value instead, which allows one to add tree items without a backing buffer (e.g., generated analysis items based on earlier traffic). And this is what you are unintentionally doing with this line of code:

local length = subtree:add(f_length,buf(0,4):le_uint());

Here's a quick breakdown of the two arguments:

  • f_length is a ProtoField
  • buf(0,4):le_uint() returns a Lua number, which is a literal value

Since the arguments passed to TreeItem.add() do not include a TvbRange, TreeItem does not know what to highlight. It simply adds the labeled value to the protocol tree.

In your rewritten code, you saw that this line:

local length = subtree:add(f_length,buf(0,4));

achieved your intermediate goal of highlighting the field's bytes upon field selection. This is because you're now passing the TvbRange needed by TreeItem.

But then you must've realized that the field value was wrong because it was shown in big-endian when you needed little-endian, so you compensated by parsing the little-endian integer from the TvbRange and setting the TreeItem's text accordingly:

local length_v = buf(0,4):le_uint();
length:set_text("length:\t" .. length_v)

Actually, this is unnecessary (and inefficient). These three lines in your rewritten code can be simplified into one by using TreeItem.add_le():

subtree:add_le(f_length,buf(0,4));

Note that TreeItem.add() uses big-endian format, and you should be able to guess what TreeItem.add_le() does. :)

answered 08 Jun '12, 03:11

helloworld's gravatar image

helloworld
3.1k42041
accept rate: 28%

thanks you!

(08 Jun '12, 03:23) PavelMSTU