 | 1 | initial version |
The behavior might be explainable due to the data being displayed in the Info column, and is trivial to demonstrate. For example, here's a simple Lua script and packet that can illustrate the behavior. First the simple Lua script:
local p_foo = Proto("foo", "FOO Protocol")
local f_foo_val8 = ProtoField.uint8("foo.val8", "Value 8", base.OCT)
local f_foo_val16 = ProtoField.uint16("foo.val16", "Value 16", base.DEC)
local f_foo_val32 = ProtoField.uint32("foo.val32", "Value 32", base.HEX)
local f_foo_string = ProtoField.string("foo.string", "String", base.ASCII)
function p_foo.dissector(buf, pinfo, tree)
local foo_tree = tree:add(p_foo, buf(0,-1))
local str = nil
pinfo.cols.protocol:set("FOO")
foo_tree:add(f_foo_val8, buf(0, 1))
foo_tree:add(f_foo_val16, buf(1, 2))
foo_tree:add(f_foo_val32, buf(3, 4))
foo_tree:add(f_foo_string, buf(7, 20))
str = buf(7):stringz()
pinfo.cols.info:set("String: " .. str)
end
local udp_table = DissectorTable.get("udp.port")
udp_table:add(33333, p_foo)
Save this to a file, e.g., foo.lua, located in your Personal Lua Plugins directory, which you can find via Help -> About Wireshark -> Folders -> Personal Lua Plugins.
Here are 2 packets of data to demonstrate:
0000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00 ..¶.....¶.....E.
0010 00 37 00 00 40 00 40 11 b5 ea c0 00 02 65 c0 00 .7..@.@.µêÀ..eÀ.
0020 02 66 82 35 82 35 00 23 e8 54 53 b2 6e 9a bc de .f.5.5.#èTS²n.¼Þ
0030 f0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 ðHello World!...
0040 00 00 00 00 00 .....
0000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00 ..¶.....¶.....E.
0010 00 37 00 00 40 00 40 11 b5 ea c0 00 02 65 c0 00 .7..@.@.µêÀ..eÀ.
0020 02 66 82 35 82 35 00 23 e8 54 53 b2 6e 9a bc de .f.5.5.#èTS²n.¼Þ
0030 f0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0a 0a 0a ðHello World!...
0040 0a 0a 0a 0a 00 .....
(To convert this to a pcap file, save the packet data to a text file, e.g., foo.txt, then run text2pcap foo.txt foo.pcap. Now you can load the foo.pcap file into Wireshark and it will be dissected according to the foo dissector provided above.)
Notice the extra newlines 0a at the end of the text in the 2nd packet? Those newlines will cause the row height to be expanded for both frames. You can see the difference if you apply a display filter such as frame.number == 1 and then close and reopen the file. Now the first frame won't have its row height expanded when you open the capture file. However, once you clear the filter and the second frame is processed and displayed, the row heights will be expanded again.
All this is just to demonstrate an example of why the row height may be expanding.