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

How to get all tree items collapsed as default in GTK+ version

0

I'm running on the nightly build. I noticed that for Qt version (either Mac or Windows), when I click on the part of the tree that I have written a dissector for, the tree is collapsed as default and you can expand it as you wish. However, for the GTK+ version (Windows), once you click on my protocol, it expands to the deepest level, which is a bit annoying. I haven't found out a way to change this. Is there a way I can make this all collapsed at the start?

asked 01 Apr '14, 10:09

YXI's gravatar image

YXI
21●18●20●23
accept rate: 0%

edited 04 Apr '14, 17:00

Hadriel's gravatar image

Hadriel
2.7k●2●9●39

Do you mean when you click on the + to expand a tree (in Gtk+) it automatically expands all subtrees?

Or do you mean that after doing that and then moving to another frame that contains your protocol all the subtrees are expanded?

(01 Apr '14, 17:59) JeffMorriss ♦

I mean when you click on the + to expand a tree (in GTK+), instead of expanding one step down, just to the children level, it expands to children, grandchildren, great-grandchildren, all the way to the leave level of the entire subtree you clicked on.

(02 Apr '14, 07:33) YXI

That's very odd. I don't see that behavior here. I'm on Linux and I tried with both Gtk2 and Gtk3.

Does it happen for other protocols as well or just yours?

What about the stable (1.10.x) version?

(02 Apr '14, 14:08) JeffMorriss ♦

Seems just to happen for my own protocol which is dissected by my script. Haven't tried on a 1.10.x version.

(02 Apr '14, 15:43) YXI

2 Answers:

3

If you're getting this behavior when using a Lua script, I think this will happen if you use tree:add() where the first argument is not a ProtoField. In some of your other posts you've had a Lua script use tree:add() with a TvbRange object for the first argument.

That's not illegal/wrong, but this is the behavior you'll get with that for the reason Bill Meier cited: internally the wireshark C-code needs a registered ett value, and the internal Lua binding code gets the ett either from the registered ProtoField given in the first argument, or if one isn't given in the first argument then it uses a single, generic ett registered for all of Lua; so expanding one of that "type" will expand all of that type. The same thing happens if you do a tree:add("foo") with just text as a subtree parent, for example.

To avoid this behavior, simply create and register ProtoFields for your subtree parents, and use the ProtoField as the first argument for tree:add().

[Qt should have given the same behavior - if it doesn't that's a bug I think.]

answered 02 Apr '14, 19:51

Hadriel's gravatar image

Hadriel
2.7k●2●9●39
accept rate: 18%

You guys hit the nail on the head! Yes, I'm using the TvbRange as the first argument in tree:add() I do need to change to using ProtoField as the first argument as that will make my value filterable as well.
Thanks.

(03 Apr '14, 07:30) YXI

1

Are you using the same 'ett' variable for each level (subtree) ?

If so, that will give exactly the effect you describe (at least using GTK).

If this is the problem, it would appear that there's something different (from GTK Wireshark) about the Wireshark implementation of trees when using QT (which might possibly be a bug).

(An ett variable keeps track of whether the associated sub-tree is expanded or not; if only a single variable is used for all the sub-trees, then expanding one sub-tree effectively expands all the sub-trees).

answered 02 Apr '14, 19:33

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k●1●8●50
accept rate: 17%

Hello guys as per above answers and comments my below script should work and show only level_1 children only but behaves same as older one

-- New Protocol and  fields
p_mynewproto  = Proto ("MyProtocol", "Test")

– Define Header fields
local protoHeader = p_mynewproto.fields
protoHeader.rxId        = ProtoField.uint16('protoHeader.rxId'      , 'Rx ID ' , base.HEX, nil)
protoHeader.txId        = ProtoField.uint16('protoHeader.txId'      , 'Tx ID ' , base.HEX, nil)
protoHeader.timeHour    = ProtoField.uint16('protoHeader.timeHour'  , 'Hour  ' , base.HEX, nil)
protoHeader.timeMinute  = ProtoField.uint16('protoHeader.timeMinute', 'Minute' , base.HEX, nil)
protoHeader.timeSecond  = ProtoField.uint16('protoHeader.timeSecond', 'Second' , base.HEX, nil)


– mynewproto dissector function
function p_mynewproto.dissector (buf, pkt, root)


– Check the packet length
if buf:len() == 0 then return end
pkt.cols.protocol = p_mynewproto.name


– start from offset 0
local offset = 0


– create subtree for mynewproto
subtreeA = root:add(p_mynewproto, buf(offset,buf:len())):append_text(" [My Protocol Header]")


– Rx ID
subtreeA:add(protoHeader.rxId , buf(offset,2))


– Tx ID
subtreeA:add(protoHeader.txId , buf(offset+2,2))


– Time
subtreeB = subtreeA:add(p_mynewproto, buf(offset+4,2),"[TIME]")
– Time Hour
subtreeB:add(protoHeader.timeHour , buf(offset+4,2))
subtreeC = subtreeB:add(p_mynewproto, buf(offset+6,4),"[minute and second]")
– Time Minute
subtreeC:add(protoHeader.timeMinute , buf(offset+6,2))
– Time Second
subtreeC:add(protoHeader.timeSecond , buf(offset+8,2))
end


– Initialization function
function p_mynewproto.init()
end


– Register a chained dissector for port 11111
tcp_table = DissectorTable.get("tcp.port")
– register our protocol to handle udp port 7777
tcp_table:add(8443,p_mynewproto)
(18 May ‘15, 23:38) ankit

I don’t know why ankit has posted my code https://ask.wireshark.org/questions/42404/lua-dissector-tree-collapse What’s the scope of his answer :O ?

(19 May ‘15, 04:18) Peter1969

Hi peter I have also the same doubt. I have developed one plugin using lua ans same problem has occured as you have mentioned in your question. I have just reused your code to ask doubt nothing else let’s see what answer will be given??!!

(19 May ‘15, 08:32) ankit

@Hadriel can you look into this?

(20 May ‘15, 09:44) ankit

Answered in the original question.

(27 Jun ‘15, 19:21) Hadriel