Ask Your Question

Expanding rows

asked 2018-12-10 12:57:32 +0000

Mike Honcho gravatar image

updated 2018-12-10 13:04:00 +0000

Hi, I have this ongoing problem on Wireshark in which all rows in the UI will suddenly expand to around 6x the standard row height, creating huge amounts of blank space. (I'd upload a screenshot except I don't have permissions)

Unlike column width there doesn't seem to be a way to readily change row height, and reloading the pcap is the only solution. This becomes very arduous and I usually give up whatever I was trying to do.

I found these reported bugs which sound similar to my issue, but it's beyond my ability to follow the technicalities. I've also noticed, as reported below, that the expansion happens when I click on, or simply scroll past, a particular packet.

Bizarrely this problem seems to persist even through updates and clean re-installations. Perhaps I can add a line to qt.conf to permanently fix the row size to 1? I believe there are Qt functions such as uniformRowHeights() which may enable me to do this, but I don't know how. At this stage I'd be very happy with any kind of "hack" to fix the issue.


Wireshark version: 2.6.5
OS: macOS High Sierra 10.13.6

edit retag flag offensive close merge delete


I found an earlier bug report here, but this may have only fixed the problem for LDAP specifically?

Mike Honcho gravatar imageMike Honcho ( 2018-12-11 13:15:01 +0000 )edit

Yes, this was a fix for LDAP specifically. The expanding rows is actually by design, see comment 5 and bug 10924. So one mans bug is another mans feature it seems...

Jaap gravatar imageJaap ( 2018-12-11 18:20:05 +0000 )edit

3 Answers

Sort by » oldest newest most voted

answered 2018-12-11 13:13:24 +0000

Mike Honcho gravatar image

OK, I found a fix for anyone interested: Edit > Configuration Profiles... > Classic

This profile has harsh colours compared to 'Default', but you can easily export the colouring rules from Default (View > Coloring Rules...) and then import them to Classic

I don't know what the pertinent difference is between these two profiles but hey, it works

edit flag offensive delete link more


Changing profiles doesn't help for the example I provided. It's strange that it helps in this case. As Jaap suggested, you might want to file a bug report for this anyway so that folks don't have to change profiles to work around the problem. And really, that's all it is - a work-around, not a fix. Perhaps you can't upload an entire capture file to the bug report, but if you can isolate the packet causing the row height to expand, then maybe that would be OK for you to upload? If not, then can you at least identify which protocols are involved with that packet?

cmaynard gravatar imagecmaynard ( 2018-12-11 14:43:26 +0000 )edit

Here's just one example which causes the problem for me; pcap "1 of 2" on this webpage:

Packet 48 (an HTTP GET) has the \r\n characters. Curiously, it's only when I proceed to packet 49, either clicking or scrolling past, that everything blows up.

One reason I didn't make a bug report is because I noticed the verdict here is that it wasn't a bug!

Mike Honcho gravatar imageMike Honcho ( 2018-12-11 17:43:35 +0000 )edit

I am running Wireshark 2.6.5 on Windows 10 and I don't see the rows expand when selecting or scrolling past Packet 48, no matter which profile I use. This might be a MAC-specific problem then? Maybe post your Help -> About Wireshark details? Here's mine for reference:

Version 2.6.5 (v2.6.5)  

Compiled (64-bit) with Qt 5.11.2, with WinPcap (4_1_3), with GLib 2.42.0, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS 3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.14.0, with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia, with AirPcap, with SBC, with SpanDSP, with bcg729.  

Running on 64-bit Windows 10, build 17763, with Intel(R) Xeon(R) CPU E3-1505M v5 @ 2 ...
cmaynard gravatar imagecmaynard ( 2018-12-11 18:05:29 +0000 )edit

answered 2018-12-10 17:33:33 +0000

cmaynard gravatar image

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


    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()"String: " .. str)

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 ... (more)

edit flag offensive delete link more


Hey, thanks for your answer. I think you've located the problem. In the example I'm looking at now (not the one you posted), the offending packets end with newline bytes such as 0d 0a 0d 0a 00 00...

However the problem doesn't go away even if I get rid of the info column.

Mike Honcho gravatar imageMike Honcho ( 2018-12-11 09:40:37 +0000 )edit

answered 2018-12-10 13:29:56 +0000

Jaap gravatar image

It's a bug, so why not opening a bug report? Attach the capture with offending packet and the developers have some concrete to work with.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-12-10 12:57:32 +0000

Seen: 2,170 times

Last updated: Dec 11 '18