Wireshark 2.0: Now with Qt
The headline feature for Wireshark 2.0, which was released on November 18, is the switch away from GTK+ and to the Qt framework, but there is more to it than just that. The bulk of the changes to Wireshark—the venerable free-software network packet sniffer that started out as Ethereal in 1998—come under the heading of user-interface improvements, but that leads to some improved functionality as well.
The switch to Qt was announced
back in October 2013, so it has taken around two years to complete the
switch.  The main reason behind the change was to better support Mac
OS X, which is something of second-tier platform for GTK+.  In
addition, Qt will make Android and, possibly, iOS versions possible as well.  Based
on a blog
post from Wireshark founder Gerald Combs, Qt has also helped make the interface
function "much more smoothly
".
Combs noted that the new interface looks largely the same as the previous version, which is intentional.
![[Wireshark]](https://static.lwn.net/images/2015/wireshark-2-sm.png) 
At its core, Wireshark provides a way for users to capture packets on the local network, then to display them for analysis. The basic three-pane display, with a pane for a list of packets captured (i.e. the "Packet List" pane) and two that show details of the currently selected packet, looks much the same. The packet-specific panes show a decoded version of the packet that splits out various fields in it (Packet Details), while the other shows a hex and ASCII version of the packet (Packet Bytes). There is also a toolbar, display filter entry box, and a menu at the top (as seen at right for 2.0.0rc2 from Combs's post).
![[Scrollbar]](https://static.lwn.net/images/2015/wireshark-scrollbar.png) 
There are some things that have changed in the analysis interface, however. Packets related to the one selected in the packet list now have icons to indicate that status. For example, DNS requests and replies have left and right arrows and TCP packets that have been acknowledged have a check mark next to them. In addition, the packet list scrollbar shows a "minimap" of the color of packets nearby in the list—similar to the minimaps in modern text editors. When combined with rules that display different types of packets in various colors, it can help find more interesting portions of the captured packets. The minimap from the screen shot above can be seen at left.
In a webinar [YouTube] given on November 12, Combs and Laura Chappell demonstrate some of the features in the new interface. Many things have been streamlined in the Qt-based interface, they said. But, the GTK+ interface will still be supported until the next stable release, which will be 2.2—odd minor numbers are for development releases.
Some of the examples shown in the webinar were things like an improved interface to choose a saved filter to apply to a capture. Previously that required bringing up a separate window that listed all of the saved filters to choose from; now that can be done directly from a menu just to the left of the filter entry box in the main window. Hiding and showing columns in the packet list can also be chosen directly from a menu that comes up when right-clicking the column headings. The interface for setting coloring rules has also been improved so that colors can be chosen from a "picker" rather than having to enter color names.
There has also been some cleanup done in the toolbar to remove clutter, as well as rearranging the main menus somewhat to put functions in more natural locations. For the graphs and statistics windows, there is no longer a step to choose settings before seeing the output; those settings are available at the bottom of the window, so if the standard output with no filter is all that's needed, users get that immediately.
There are many more keyboard shortcuts in Wireshark 2. The full list of those shortcuts can be found from the "Help" menu. In addition, individual windows have their own shortcuts, which can be listed from the window itself.
The capture screen, which initiates the packet capture process, has been streamlined as well. There are now small graphs of packet activity for each interface (called sparklines) that can be double-clicked to start a capture on that interface. Those can give users a quick idea of how much traffic is being seen on each interface in the system. Many of the options in the somewhat busy GTK+ capture window have moved to a separate options window (which has its own sparklines).
There is plenty more to the interface that is shown in the hour-long webinar. It is worth a look for those interested in more information. A zip archive of the trace files used in the demonstration are available as well.
Wireshark 2 has been localized for seven languages for the release. Chinese, English, French, German, Italian, Japanese, and Polish versions are available and more translations are currently being worked on. The project uses a Transifex site for that translation work and Combs invited those interested to join in the efforts.
In addition to the upgraded interface, lots of bugs were squashed in the release, including a number of security holes. Over the years, Wireshark has gotten something of a bad reputation for its security track-record. As the Wireshark security page indicates, the program is tasked with dealing with enormous amounts of user-supplied data using "dissectors" to parse and decode many different formats, including experimental ones. That's not an excuse for the large numbers of bugs that continue to be found, but most of the code in Wireshark is in the dissectors, which means that the bulk of the bugs found will be security issues.
There are a number of things that can be done to reduce the damage that a capture (or, worse, an attacker-supplied capture file) can do in the presence of dissector bugs. For example, Wireshark should never be run as root and captures can be done with a simpler program (e.g. tcpdump) and then imported into Wireshark running in a limited user account or dedicated machine (virtual or otherwise). In addition, the page lists several ongoing efforts to find and remove bugs from the code, which are further fleshed out on a dedicated security development page.
Overall, Wireshark 2 looks like a solid release that brings a lot of interface improvements. That should make it easier to work with and allow users to be more productive in their network troubleshooting and analysis.
      Posted Dec 10, 2015 12:35 UTC (Thu)
                               by pwfxq (subscriber, #84695)
                              [Link] (10 responses)
       
     
    
      Posted Dec 10, 2015 13:00 UTC (Thu)
                               by NAR (subscriber, #1313)
                              [Link] 
       
     
      Posted Dec 10, 2015 13:14 UTC (Thu)
                               by pizza (subscriber, #46)
                              [Link] (1 responses)
       
     
    
      Posted Dec 12, 2015 9:18 UTC (Sat)
                               by Lekensteyn (guest, #99903)
                              [Link] 
       
     
      Posted Dec 10, 2015 13:20 UTC (Thu)
                               by jlayton (subscriber, #31672)
                              [Link] 
       
     
      Posted Dec 10, 2015 17:59 UTC (Thu)
                               by iabervon (subscriber, #722)
                              [Link] (3 responses)
       
 
     
    
      Posted Dec 10, 2015 20:00 UTC (Thu)
                               by bronson (subscriber, #4806)
                              [Link] (2 responses)
       
I assume the catch is that Wireshark is cross-platform and sandboxing is not.  Very very not. 
     
    
      Posted Dec 10, 2015 22:33 UTC (Thu)
                               by johill (subscriber, #25196)
                              [Link] (1 responses)
       
I think the cross-platform angle seems a bit of a red herring; once you've split it out to a separate process you could get the security where it's supported? 
     
    
      Posted Dec 11, 2015 15:27 UTC (Fri)
                               by raven667 (subscriber, #5198)
                              [Link] 
       
It seems you only need a file descriptor in/out, input would be pcap data, output would have to be structured for consumption by the Wireshark UI, which provides its own attack surface and potential for failure, but it should be lower than that of the dissectors themselves, even as the dissectors are re-written in a safer way.  How is that done in browser land, what validation does the display process have of data being fed from the parser? 
     
      Posted Dec 11, 2015 7:34 UTC (Fri)
                               by robbe (guest, #16131)
                              [Link] (1 responses)
       
More interesting at the moment would be privilege-seperating the dissectors from the GUI. They are a prime example where even simple seccomp could do wonders. 
     
    
      Posted Dec 12, 2015 19:18 UTC (Sat)
                               by jmayer (guest, #595)
                              [Link] 
       
     
      Posted Dec 15, 2015 5:59 UTC (Tue)
                               by ploxiln (subscriber, #58395)
                              [Link] (3 responses)
       
It's disappointing that the main Wireshark site never offered a non-x11, gtk+3 OS X build. 
I'm sure they had other reasons to want to do a UI re-write with QT though, and I don't think less of them for that. 
     
    
      Posted Dec 17, 2015 8:54 UTC (Thu)
                               by thumperward (guest, #34368)
                              [Link] (1 responses)
       
     
    
      Posted Dec 17, 2015 13:22 UTC (Thu)
                               by jospoortvliet (guest, #33164)
                              [Link] 
       
     
      Posted Dec 18, 2015 23:49 UTC (Fri)
                               by jmayer (guest, #595)
                              [Link] 
       
     
    Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Priviledge Seperation
      
Seriously though - it could probably be done since the dissectors interact with an abstract representation of the parse tree, but you'd have to serialize that across some kind of protocol which is likely quite awful ...
Priviledge Seperation
      
Privilege Seperation
      
Privilege Seperation
      
Wireshark 2.0: Now with Qt
      
Wireshark 2.0: Now with Qt
      
Wireshark 2.0: Now with Qt
      
Wireshark 2.0: Now with Qt
      
http://www.phoronix.com/forums/forum/software/general-lin...
It's mostly about stable APIs and a bit about multi plaform maintenance.
 
           