Wireshark Wishlist

The following is a list of features that have been requested for Wireshark.

Before adding anything to this list, ask the developer mailing list about the feature you would like to see!

Although it's not a requirement, it would be nice to add your name to a new item, as a lot of ideas have only a very short description without many details, and therefore misunderstandings appear frequently.

Please don't add entries such as: "I would like to see a current binary release for platform XY", this is not a feature of Wireshark.

If you want a new protocol added or changes to an existing one made, capture files and references to specification documents would help to get them developed.

Contents

Wireshark Wishlist

General / Unsorted

In other sniffer applications I have seen a very useful feature which counted metrics of network traffic without storing the details of the packets captured. For instance, keep a running tally of how many bytes are sent to/from every host without actually storing the details of the traffic. This is useful because I might have a host that has a tremendous amount of traffic and for which I want to monitor for a long period of time (8+ hours) to see if any unexpected inbound or outbound traffic is occuring. From a memory perspective, it's not desirable to store the full details of 8 hours of high-volume traffic. Storing the aggregate byte counts or other key metrics would use a trivial amount of memory. One use of this is to see if errant system backups or processes are running that might interfere with a batch schedule. -Frank R
Bounce diagrams. In some situations it would be very helpful to see the TCP traffic in form of bounce diagrams (W. Richard Stevens calls them "timeline diagrams" in his book "TCP/IP illustrated"). Maybe use graphviz for the illustration task? - Ph. Marek I think we already have bounce diagram code in the VoIP plugin; that code could perhaps be made a general bounce diagram module for use in other tap listeners, including a TCP tap listener to draw bounce diagrams. -Guy Harris
Packet generation. (Does this mean letting you edit the contents of a packet and send the result, or some generator to send multiple packets, or both? -Guy Harris.) I assume this is playback of packets. I would love to see a plugin where you can design the packet, set the packet rate and probably some additional parameters and then let Wireshark to generate the packets on the selected interface. If then Wireshark would allow to pair 2 ethernet interfaces it would allow to test network latency or throughput by comparing data transmitted on one port and recieved on other. The example of the packet generation functionality can be packeth software packeth.sourceforge.net.
A playback window, with real-time or accelerated/decelerated playback. ("Playback" in the sense of re-transmitting the captured packets? -Guy Harris) (If I remember correctly, I brought up this one and I meant you could watch the packets arriving like you could see them with TShark, or with Wireshark when "update the packet list" is switched on during live capture. - Olivier Biot) (I would love to see this!)
To manually compare captures, it would be nice to see a hash/checksum (one of MD5, SHA-1, CRC-32) on every protocol-level, which hashes this level and all data below; so the verification/correlation of packets (despite usage of NAT or something similar) would be easier. This would also allow detect packet corruption. For my use-case it would not have to be stored, only given for the current packet - so the performance loss would be negligible. For packet correlation it would be persistent, though. -Ph. Marek
More printing options (e.g. print preview, landscape mode, different paper sizes, etc.) (Using native printing mechanisms and native print dialogs might help here - we already use a native dialog on Windows, and use the native mechanism in a somewhat kludgy fashion, which we should fix - as might providing a way to export those options to be usable from our own print dialog. -Guy Harris)
For TShark, provide a way to control the output format. E.g., 'tshark -e "ip udp tcp.port"' would expand the IP and UDP sections, and display the TCP port information.
We might want to have a Windows Pocket PC 2003 distribution. - Ulf Lamping (This would require the Windows CE version of WinPcap, as well as either GTK+ and GLib for Windows CE or a version of the native Win32 Wireshark for Windows CE. - Guy Harris) (For CE 4.2 and up, check out the Netlog tool that comes with CE, which writes out captures in Microsoft Network Monitor format, which Wireshark can read.)
A protocols poster (or series of posters ).
It would be nice to get properties of last used interface (IP, MAC, network) for use as variables in display filter or coloring rules.
PDML output has several fields that do not have a name attribute assigned to them. This creates difficulties in parsing and offline analysis of the XML output from Wireshark. e.g. IP address field in a DNS response does not include the name attribute. (Fields added to the display using proto_tree_add_text() don't have a name related to them. This wish requires the abolishment of this function. Or will an empty name/showname attribute suffice? - Jaap Keuter) (Alternatively, we could just suppress unnamed fields from the PDML output, and turn unnamed fields to named fields as people complain or submit patches. A sweeping change of all unnamed fields would probably only happen over a long period of time. - Guy Harris)
Add an automatic update feature for Win32. In comparison to most *NIX distributions Windows doesn't provide a "system wide" way to update applications, so each application has to do it on it's own. Well known applications like Firefox recently added such features. For security (and other) reasons it's also desireable to use the latest available Wireshark version. Wireshark could check once a week if a new version is available, and it it is, asking to install it or not. Of course, this feature should be configurable: Check: "Never", "Every week", "Every month", with the default probably to "Every week" - Ulf Lamping
Allow developers to write plugins that can walk the protocol tree data structure to allow efficient forms of exporting and report generation. All current text/PDML output is too large to efficiently process in anything but small captures. The first enhancement would be for TShark to allow these plugins. The second enhancement would be to put dynamically loaded plugins into the Export(?) menu. - Allan Clarke
Editcap new features:
- simulate packet loss
- simulate packet misorder
- using pcap filters to apply the "noise" only to some packets that match

Installer

Add the user's guide to the various installers, to have it at hand when a question comes up. This way, we could even add a link from various places in the GUI to have some sort of "online help". - Ulf Lamping
Provide a .zip or .7z package with the windows binaries. The installer doesn't do anything more than copy them anyway.

Capturing

The ability to attach to a specific process and capture traffic to and from that process. This is a bit like a debugger, and definitely platform dependent. However, this would be tremendously useful for doing things such as malware analysis and other things without having to write lengthy capture or display filters. (Very platform-dependent, and it requires a definition of what "to and from that process" means; presumably it means "to and from endpoints for sockets for which the process has descriptors/handles", if this is referring to capturing on a network interface, and means "somehow attach to all the process's sockets and see traffic on them", otherwise - the latter is trickier as Wireshark is designed to be a network capture and analysis program, and IP headers might have to be synthesized to make the traffic look enough like network traffic that Wireshark's mechanisms, including those that expect TCP or UDP packets to have IP addresses associated with them, e.g. for endpoint identification, to work. - Guy Harris) -- Note that Windows has the ability to provide this information, at least at some level; try running "netstat -o".
The ability to capture from multiple interfaces at once.
Ability to capture from an interface which doesn't exist yet. It would start actual capturing when the desired interface is created. Then it would be possible to see traffic from a ppp* interface immediately when the connection is established. (Note that this would probably require libpcap/WinPcap work and might even require OS kernel work to support that - Guy Harris)
Ability to capture (and later dissect) from USB and FireWire ports on those platforms that support it.
The ability to set up "Alarm filters", which start a capture. You would start the capture engine, but until something special happens no packets are captured. So you can do a long term capture run and wait for a special network event, without getting tons of capture data.
The ability to set up "Alarm filters", which stop the capture, run a command or play a sound when a match is found. (Note that the way you play a sound is platform-dependent - Windows, OS X, and various UNIX+X desktops have different APIs for playing sounds.)
The Alarm feature would be nice although you may want to separate it into alarms and triggers where the former could be set up using both start and stop capture/display filter and/or time criteria. The stop capture criteria could also include relative to start time (like 5 minutes worth of data). Both features could be set up to send out email alerts. - Mark Johnson
During live captures, display the user and process name/ID information associated with each local network connection (Where to display that information? - Ulf Lamping). (More important - how to get that information? It might not be available on all OSes, and even on those where it's available, the way to get it is platform-dependent. -Guy Harris.)
Add start capture time. when you click 'Capture' -> 'Start' a window pops up where you can stop the capture at said time. Say I want to do a base run for a 3 hour window on Sunday when nobody (including me) is in the office. It would be nice to start a capture at 12 and stop at 3 automatically! (Another item said "Implement an ability to start/stop captures on at a certain time (i.e. very late at night!) based on a scheduled command after capture preparations have been made - Preston Gallwas"; I'm presuming that's the same thing. -Guy Harris)
Regarding ring buffers, the duration test is very useful. It would be nice to be able to set a maximum "combined" filesize limit. For instance, if I had a 10GB drive where I was having it save files every hour (regardless of size), once 10GB of data was reached, it would delete the oldest file(s) before saving the next. Similar to how the "filesize" ring buffer currently works. - Mark Johnson
Unify the capture and display filter syntax somehow. One approach might be to build a subset of the display filters suitable for capture filters and do a syntax translation. - Ulf Lamping I.e., have a capture-filter translator that generates "libpcap"-style capture filter expressions, with a capture filter syntax similar to the display filter syntax. (The syntax differences get in the way of users; the fact that you have to construct some filters by hand, e.g. looking only for initial SYN packets for TCP connections by doing bit-testing of the flags in a TCP header has been a pain for some users; and people have asked for capabilities that aren't conveniently available, or aren't available at all, in "libpcap"-style capture filters:
- the ability to filter on characteristics of IPX packets;
- the ability to select, for example, TCP packets with port numbers *greater than* a particular value, which in "libpcap" filters you have to do by explicitly testing subfields of the TCP header rather than doing "tcp.port > 1000";
- etc.)
Instead of converting Wireshark-style filters to pcap-style ones, you may directly convert Wireshark filters to BPF filtering code (may be not cross-platform).
Another possibility would be to add to the syntax for display filters filters with the syntax of capture filters. Support for display filters such as host hostname might reduce confusion about how to select packets that don't go to or from a particular host - instead of having to explain that the inverse of ip.addr == hostname is !(ip.addr ==) hostname, not ip.addr != hostname, people could just use not host hostname as the opposite of host hostname.
Handle IPv4 mapped addresses when automatically generating capture filters on dual stack hosts (get_conn_cfilter() in util.c). Every IPv6 address matching ::FFFF:a.b.c.d should be replaced with IPv4 address a.b.c.d before generating the filter. (Replaced with, or augmented with? I.e., will traffic to and from addresses such as that be sent as IPv4 traffic? -Guy Harris) (Yes exactly. See RFC3493 (sections 3.7 and 6) and RFC3513 (section 2.5.5) - Anthony Baire)
Allow display filters for capturing live data. It would be very beneficial to use filters like [frame contains "rror"] to log possible issues. It could also offer a nice segue into the possible future addition of triggers. - Mark Johnson ("the ability to use a read filter when capturing, so that a capture can, for example, save only packets that match a particular pattern and discard the rest". Triggers are a separate issue; triggers could be implemented without read filters - just use capture filters. -Guy Harris)
Provide a "Circular" capture file. It would be nice to be able to specify that I want a xMeg capture file and that I want the contents to wrap when full rather than stopping or requiring that you move to another file in a ring buffer. (This is currently not possible with the libpcap file format we use, and probably with none of the other file formats we support. Implementing this would require to define a new file format, and do a lot of effort in Wireshark itself to support this. - Ulf Lamping) (This could be done with an in-memory circular buffer; I think that's how a number of other capture programs work. The disadvantage of that is, of course, that you're limited by the size of the buffer. - Guy Harris)
Ability to read pcap file "tail -f" way or to read from stream. It would make possible to use Wireshark like that:
- ssh root@somehost "tcpdump -i eth0 -s 1500 -w -" | wireshark
(It's already possible, on UN*Xes that support named pipes - most, if not all, do so by now - to do
- ```
mkfifo /tmp/wireshark_pipe
ssh root@somehost "tcpdump -i eth0 -s 1500 -w -" > /tmp/wireshark_pipe
```
and then have Wireshark capture from /tmp/wireshark_pipe. We could add support for "-" as an argument to "-i", although probably not as something you can specify from the GUI, so that you could do
- ssh root@somehost "tcpdump -i eth0 -s 1500 -w -" | wireshark -k -i -
If you're reading from a live capture, that's more like capturing than like reading a file, so it makes sense to implement it as capturing rather than reading.
Of course, with a future version of libpcap, you might do that by specifying something such as ssh://root@somehost/eth0 as the capture device, with libpcap implementing that by SSHing to "somehost" as user "root" and running the command tcpdump -i eth0 -s <snaplen> -w - and reading from that connection, along the lines of the syntax used in WinPcap for the rpcap protocol. -Guy Harris) (-i /dev/stdin would not be sufficient, as the underlying problem is that Wireshark requires random access to the underlying file, and, even on systems that support /dev/stdin, which not all OSes on which Wireshark runs do, if you're piping to Wireshark, /dev/stdin is a pipe and doesn't support seeking, so Wireshark, which support randomly selecting packets to view and thus requires random access to the input file, won't support reading from /dev/stdin).
Capture the customer defined message flow. for example: WAP message flow including RADIUS, WSP to WAP gateway, HTTP from WAP gateway to SP, and SP back to gateway, gateway back to mobile phone, the capture filter can be apply by mobile phone number (MSISDN). (What exactly are you asking for here? Is all the traffic you're describing available to a device on a single machine, or is it flowing over several networks? If it's flowing over several networks, you can't capture it in a single session of Wireshark - you'd have to capture the different pieces on different systems. -Guy Harris)
Add a feature to Capture-Options to use multiple files with an new option "Next file every" x PACKETS! (What's the use of it? In a tradeoff between complicating the options dialog box even further and getting a useful new feature, this feature is loosing. - UlfLamping)
Ability to specify the time of day to move on to the next file in "Capture Options", Capture File(s)", "Use multiple files", "Next file every 1 day(s)". So when the capture files are to be from 12:00 AM to 12:00 AM, the capture can be started at anytime and not have to wait till 12:00 AM to start the capturing. - Al Stu
Ability to do a "database mode" just like Sniffer Pro. The database mode simply makes a summary of the traffic with source IP, protocol and number of bytes sent in a user specified time period. The output file is a csv file. Atari_Mark
Add a button to Capture to insert a time reference at that point of the capture stream. Then, once the capture is done, the user could easily flip between time references to find traffic of interest (rather than having to insert the time references after the fact). -JoshKelley You can do that now if you're doing an "Update list of captures in real time" capture. If you're not, "that point" might not refer to any particular identifiable point, but it could make a list of packet numbers at which references should be added when the capture is read in. (Note that time references aren't stored in the capture file - libpcap doesn't support that.) -Guy Harris
Implement on various UN*Xes as many of the currently Win32-only additional bits of information in the "Interfaces" dialog. This would be platform-dependent for now, although I want to implement as many of them as possible in a future version of libpcap/WinPcap, which would, at least when Wireshark is built with and runs with that version of libpcap/WinPcap, push the platform dependence into libpcap/WinPcap. -Guy Harris
The "ring-buffer" mode of dumpcap is a very powerful feature. We use it on several boxes to maintain a constant "sliding window" of all traffic so if an issue comes up, we always have all the packets involved. We use it with parameters like {-b "files:870" -b "filesize:16000" -w "D:\PKT"} which will capture to 16MB files with the prefix of "PKT" until 870 files are captured after which point, it starts the process of deleting the oldest file to save the current in a continuous manor. Unfortunately, it appears to keep the ring-buffer file names in memory since if the machine is shutdown, rebooted and/or the process is somehow stopped, a restart of the the process forgets all the previous files names and starts a new batch of (870 in this case) files thus filling the hard drive until it runs out of space. Therefore, it would be great to come up with a method for it to continue the ring capturing after a restart without first having to delete all previous trace files and losing valuable packet data. - Mark Johnson

Data I/O (e.g. Files)

A way to export all tcp streams. Much like the current 'Follow Tcp Stream' function in the gui but extended to create a file (or one for each direction) containing the data of each tcp connection between each host. (One file per host, per port pair, optionally per direction) While Follow Tcp Stream is great, it is inconvient to use when many seperate (temporally short) connections are made. In my case xml is being passed so no extra packet data is nessicary, just tcp payload. -Alex Faucher
An option to compress capture data as it's written to disk. Currently we can read gzip compressed data (autodetected) but we cannot write compressed data.
The ability to dump packet data/info into an SQL database. (How would the schema for the database be specified, and how would the information to be dumped to the database be specified? A change that hardcodes a particular schema and set of data to be dumped would be of limited use. -Guy Harris)
A command line utility which acts likes an AWK wrapper for TShark where the patterns are display filters and the selected packet's field names become possible output variables. A feature like this would allow one to create reports and/or files which could be imported into databases. - Mark Johnson
A command line utility to extract reassembled data from captured dumps (http, ftp, etc..). A switch could also be added to output followed streams into separate files. (real time would be nice as well ) - Mark Johnson
A capability added to TShark to allow multi-capturefile processing without the need to merge. When doing continuous captures with multiple (more manageable) rotating files you may end up with hundreds of files with the need to locate and extract certain data. It would be nice to use TShark's display filtering over all the files to produce a single capture file. - Mark Johnson
The ability to work with files larger than 2GB on systems that support it. It looks like there was some discussion a few years ago, but it never made it past discussion. ( kyphros@gmail.com ) (Note that zlib is one of the problems here, as it doesn't have a 64-bit file offset on all platforms. Zlib has other problems, some related to file offset size bogosity; a significant problem is that it doesn't do efficient random access. We might want to do our own decompression at some point. -Guy Harris) (Note: sgzip does not provide random access to gzipped files; it defines its own file format, which better supports random access. bzip2 format is also better for random access, and might be more commonly used. -Guy Harris)
Add an option to TShark to export CSV files, just as we do with Wireshark already. - UlfLamping ("-T csv"? This does raise the question of what should be in the CSV list, though; currently, it exports the columns in the summary list, but do we also want an option in the GUI in Wireshark to select a set of named fields to export, and something on the command line in TShark for the same purpose, e.g. "-T csv,frame.number,ip.src,ip.dst"? - Guy Harris)
The ability to edit the fields of any packet at any protocol level and save the trace. Wireshark would automatically compute the checksums. - 'Ali'
Netflow traces import/export.
I'm still using mergecap version 0.10.13 since it's the last version which allowed wildcards for infiles. It would be nice to reintroduce (fix?) that feature in the current version so a command like "mergecap -w out.cap *.cap" would merge all files with the ".cap" extension. - Mark Johnson; On UN*X, command-line applications don't see wildcards unless you quote them, so that's just a question of whether the app supports multiple arguments (the shell expands the wildcard and passes all the matching file names as arguments). I don't know what happens with the Windows command interpreter and C startup routine. Is this on Windows or on UN*X? -Guy Harris; The problem exists on every Windows version since 0.10.13. Quoted or not quoted, it doesn't matter, it just will no longer allow wildcards for file input. - Mark Johnson

Display filtering

Allow packet summary and packet dissection as valid "fields" in display filter tests:
- summary matches "(?i)response"
- dissection contains "Unknown"
I'd like to someday re-write the display filter routines to have a more powerful syntax. (This was from the old TODO list; I don't know whether it means a syntax more powerful than what we have now, or whether the "more powerful syntax" is what we have now, with the rewrite having already been done. -Guy Harris)
Add support for case insensitive filters (to deal with mgcp endpoint ids and etc). (In the current SVN version, there are upper() and lower() operators to convert fields to all-upper-case or all-lower case; a comparison can then be done against an all-upper-case or all-lower-case string.)
Add readline-like support to the display filter dialog box, e.g. tabbing ip. would result in ip.src, ip.dst, ip.host and so on.

GUI

A collapsed packet view where each packet is represented by a "small" dot. Think old Microsoft disk defragmentation detail display. Packets would have color coding via rule matching. This would be extremely benficial for TCP packets to see the big picture for application flow.
A dialog for capture filter construction "Add Expression...".
Add syntax check to the capture filter dialog (see: function pcap_compile() in capture.c), like in the display filter dialog. (This might work best with some libpcap API changes I might be able to do in my Copious Free Time(TM), namely having a routine to compile filter strings to an expression tree and separate routines to generate code and install a filter - which would make it easier to install non-BPF filters such as the CMU/Stanford filters supported on Solaris - and to generate BPF code. The first routine wouldn't require a link-layer type, so it wouldn't be able to check for operators supported only on some link-layer types, but that'd mean that you wouldn't either have to hold an interface open or open an interface, try to compile a filter, and close the interface for every character you type. -Guy Harris)
Add enhancements to the GUI for display filter construction as well "Add Expression...", to allow construction of "and", "or", "not", etc. in filters (perhaps something such as what Network Monitor has, where you can construct a filter tree). (A redesigned filter interface as well.)
Add auto completion to the display filter field. If you start typing in the field string the rest of the filter field could be "guessed" from the possible filter fields available. This would require some thinking about how to browse through the options if multiple options are available. - UlfLamping
A "Filter..." menu that pops up when a packet list item is right-clicked. Selecting this displays a dialog that lets you add different characteristics of the packet (host addresses, protocols, etc.) to the current display filter. (Much of this is there, but it doesn't currently handle the protocol column. It also works in the packet details pane, for any entry that has a filterable field.)
Separate windows that list the conversations, hardware addresses, IP addresses, protocols, etc. that are in the capture file:
- It should have a "Filter..." popup as described in the last item.
- There should be buttons to jump to the next/previous packet list item that matches the selected address, protocol, or conversation.
- (We have this for many conversation types, but not for protocols or addresses. We don't have next/previous packet buttons, although we do have a "Find Frame" menu item that lets you do the same thing a bit more awkwardly.)
Icons for each tree view entry. (What sort of icons? -Guy Harris)
The ability to generate real-time graphs of packet sizes, types of data, response times, etc. Output should be in ASCII (data dump), GIF, or PostScript(R). Perhaps something similar to tcptrace? This could perhaps be done as part of the statistical taps we have now.
We should support selecting multiple packets in the packet list pane, and multiple lines in the packet detail pane, for the benefit of Edit/Copy (see below). If more than one packet is selected, no packet will be displayed in the packet detail pane, and any operation that only applies to a single selected packet will be disabled. If more than one line is selected, no information will be displayed in the section of the status bar for field information, and any operation that only applies to a single selected field or line will be disabled.
Selecting Edit/Copy in the packet list pane should copy packet summary information for the selected packets into the copy buffer, preferably in multiple formats (plain text, CSV, ...). (Should this now be marked as done (post 0.99.5)? - Doug Pratley)
Selecting Edit/Copy in the packet detail pane should copy packet data for the selected lines into the copy buffer, preferably in multiple formats (plain text, raw binary, and possibly some other formats depending on the field or fields). (Should this now be marked as done (post 0.99.5)? - Doug Pratley)
The ability to cut/copy/paste packets in the packet list. (As "cut" is mentioned, this presumably refers to the raw packets, rather than to the later item for copying the summary line text so that it can be pasted as text; for "copy", if we also want to support the "copy text of summary of selected packets" mechanism mentioned below, presumably we'd want "copy" to support multiple formats for the clipboard item in question - packet data for pasting in Wireshark, and text data for pasting in places that expect text. -Guy Harris) (I've tried to implement multiple formats - copying code from gnumeric - but the function gtk_clipboard_set_with_data (tried with Win32 GTK 2.6.3) implementation fails to use anything else than UTF8_STRING targets. - Ulf Lamping) (Copying raw packet data to the clipboard is now done (0.99.5), but it's not quite the same thing as envisaged here, certainly no ability to cut or paste back - Doug Pratley)
The ability to delete packets in the packet list. (Presumably this is like "cut", without saving the data to the clipboard. - Guy Harris)
User defined protocol display. (What do they get to define? Or does this mean that a user can supply - in, for example, NetPDL - a description of the way a particular protocol should be dissected? -Guy Harris)
The ability to mark packet list items for printing, saving, deletion, etc.. (That's currently supported for printing and saving; we currently don't support deletion, but we could support "save only unmarked frames" in addition to the current "save only marked frames".)
The ability to assign a non-DNS custom hostname to an IP address from the displayed capture. This is akin to editing the address in Network Monitor. (Having the ability to edit, load, and save address lists would be what we'd want here - and not just IP addresses. This might also give us "External data files for hosts, arp, etc." if by "arp" they meant "MAC addresses", and would also let us store, for example, well-known Fibre Channel addresses, etc., etc., etc.. -Guy Harris)
Remember resized column widths. - Zook (x2, This results in constant annoyance and an "ugly" display at times) - Kevin
The Help window should also support text search with a "Find" dialog. (There should be no help window in it's current form at all. The HTML based help, derived from the user's guide, should be our help system. This would make the current help window obsolete. - UlfLamping)
In Pane 1 / Packet List, the horizontal scrollbar seems to have been removed (at least, it's no longer available in the Windows Version 0.10.7). As the "Info" column may grow rather big for some telegrams, I miss a way to look at the complete line. - A.Mlynski (The columns are no longer autosized; removing the autosizing fixed some problems and sped up the process of reading in the capture file somewhat. Any column can be widened by dragging the separator to the right of the column's title to the right - and this even applies to the rightmost column, which is typically the Info column; you just have to drag it past the edge of the window. Widening the Info column means that the columns might not fit in the window, in which case the horizontal scrollbar will reappear. -Guy Harris)
File->Open and File->Merge: Enable selection of multiple files in the dialog to merge the selected files. - Ulf Lamping
Support for .lnk folders in Windows. If you have a folder that is a "Shortcut to XXXXX folder.lnk" in the Open Capture File window, Wireshark should jump to this folder when clicking on it. At this time, it doesn't understand .lnk folders. (That sounds like something that should be the responsibility of the capture file dialog, not of Wireshark. Unfortunately, the GTK+ dialog box doesn't, as far as I can tell, allow an application to specify that it's not interested in files and that double-clicking a folder should just go to that folder; if it did, presumably the Win32 implementation could handle shortcut files. We are now using the native Win32 file dialog box, rather than the GTK+ file dialog box, in many places in Wireshark, as of 0.99.2, and that means that, in those places, we handle .lnk files correctly. If there are any places left where we use the GTK+ file dialog box on Windows, we should do whatever is necessary not to do so, which will completely fix this problem. - Guy Harris.)
The filter field moved to the status bar works bad with full screen window, it should be a "drop up" instead of a drop down field. - Karl83 (That might be a toolkit issue - I don't know whether any toolkits either support explicitly labeling a combo box as a "drop up" widget or automatically figure out whether there's more room "up" or "down". - Guy Harris)
- At least 0.10.7 and GTK2 do implement the previous item, but in addition to that it should show the list such that the Most Recently Used Item (MRUI) is closest to the text box, within easy reach. This is true when configured for "insert into statusbar" (and sufficiently large window, see previous item). When the list drops down from "below the main toolbar" the MRUI is at the bottom of the list, furthest away from the editbox, requiring more effort to select.
- The list should be filled one way or the other depending on the placement of the filter toolbar. Since it actually depends on the drop down/drop up action of the control, it could be considered a toolkit issue, but for now we can address this by the way we fill the list depending on the placement of the list.
The filter list should have some kind of structure like a explorer directory tree. - Karl83 (Presumably that's a Windows Explorer directory tree, and presumably you mean that it should allow you to create subfolders. Network Monitor does, but that's because, as I remember, each filter is kept in a separate file, so the filter list is a directory tree. We could do that, but it'd make it harder to move your filter lists around; we could also put a tree structure into the file. -Guy Harris)
What about a filter construction with user predefined filter expressions. The effective filter would be constructed from all filter expressions with a marked check box. - Karl83 (Could you give a more detailed example? Are you, for example, thinking of something where each filter in the list has a check box next to it, and if you check more than one, it'd construct a filter that's the result of anding-together or oring-together all the selected filters? -Guy Harris)
Make it possible to mark every data in the Wireshark display with mouse and copy it to the clipboard to paste ip, mac etc to other applications. - Karl83 (The tree view isn't a text widget, so arbitrary characters can't be selected. We could support copying the text of the currently selected lines in the summary or detail window to the clipboard - there's already a wish list item for that - and you could then paste that elsewhere, although if you only wanted to copy a particular address, you'd have to edit it out. Alternatively, an additional copy operation, "Copy Value" or something such as that, could be added, which copies a text representation of the value of a selected packet detail item to the clipboard. -Guy Harris)
Add a "Help" button to various dialog boxes and link them to the user's guide (online or offline) to have a more powerful help system than today. - Ulf Lamping
Automatic highlighting of related packets.
- When a packet is selected in the list, related packets could be highlighted, so that it's easier to follow a particular conversation in a slightly noisy capture without having to create/apply/clear filters all the time. Something like this exists in the inbox in Mail in Mac OS X 10.3 (screenshot).
- One way of doing it would be to use different colours for the different protocol layers, so that if (for instance) one selects an NFS call, then the packets related to the reply are highlighted in one colour, the packets that make up the rest of the call in another, if the IP packet is fragmented, then the fragments would show up in yet another, and so on. (I guess lower-level relatedness should take preceedence, since the higher-level relatedness is implied).
- There are many other ways of showing the grouping, one could for instance draw brackets or arrows between the packets, place coloured bullet points in a column, or (if only one level is to be supported) make the text in the list items bold-faced. The best way of determining which one to pick is probably to test mock-ups on users. For instance, show a printed mock-up for a test subject for a very brief time (e.g. a second or two), and then ask them how many related packets there were on the different levels. Then pick the one which enabled users to give the best answers.
- Magnus Reftel (That sounds like an interesting approach, but this would conflict with the colouring of packets we already have and which we should keep. Do you have an idea how we could do this? - Ulf Lamping) (Yes, many Please see the revised entry - Magnus Reftel)
Find a way to display multiple appearances of the same protocol element in the packet list pane. For example: I frequently have the problem, that multiple DCE/RPC requests are inside of a single TCP packet. This results in only the last DCE/RPC request in the TCP packet will be displayed in the info column (as it will overwrite the former infos). You cannot see that there are more than one DCE/RPC element unless you look at the packet details, which is very annoying. - Ulf Lamping (col_set_fence() is doing the job for connection oriented DCE/RPC now, but other places with the same problem might remain. - Ulf Lamping)
Pick lists in the filter expression builder. For many of the attributes that one can filter on, the possible values are known (e.g. when filtering on a specific MAC address, it only makes sense to filter on one from a captured packet). For those attributes, the value field could be made to be a pick list (a.k.a. combo box), which would make users more confident on what can be entered there, and remove any risk of filters being botched by typos. In general, the value field could be made to default to whatever value the currently selected packet has for the currently selected attribute (would be a good start, and probably much easier to implement) -- Magnus Reftel
Expression dialogue navigation:
- Cursor keys should expand/contract tree branches (no shift needed)
- Pressing a key while in the Field Name pane should jump immediately to the first item beginning with that letter
- Multiple keypresses (within, say, 1sec interval) more specific, eg D-N-S <right arrow> should jump to DNS and expand the branch
- Within expanded branch, branch name should thence be ignored, so D-N-S-<right arrow>-Q should jump directly to dns.qry.type - Steve Ward
ALT (underlined) keyboard shortcuts should be *unique* throughout the interface. At present, the ALT-F, E, C, and A shortcuts are doubled on the menus and on the toolbar, leading to inconsistent results, and confusion. - Steve Ward
Run-time configuration of data shown in capture statistics window. (From the TODO list. What sort of configuration? -Guy Harris)
Make sure that if the window system is shut down, Wireshark gets notified and:
- if there's a capture in progress, it asks whether you want to stop the capture (or just stops it for you)
- if there's an unsaved capture file, it asks you whether you want to save the capture file (assuming you haven't told it not to ask);
- and delays the shutdown until the questions are answered, if possible. This probably Just Works on UNIX+X, at least with desktop environments such as KDE and GNOME, as they probably send "delete window" events to all top-level windows, which is equivalent to clicking the close button that most window managers provide. This might work in the Mac OS X desktop environment as well; the native Aqua even is delivered either to the X server or quartz-wm (I don't know which, possibly both), which warns you that there are X applications running, but I don't know if it delivers "delete window" events to the windows if you say "yes, shut down anyway". I don't know what happens on Windows with GTK+; make sure this does the right thing.
Add "Follow TCP Stream" command to the Conversations - TCP window.
We might want to have some more task oriented GUI elements (wizards, druids, or however you call it). The first thing that comes to my mind is a wizard to start a capture. The current capture options dialog provides a lot of options. However, some people like this while others may not. - UlfLamping
Add "user defined" columns. The current columns are limited to the built in "hard coded" types. It would be nice being able to add the content of a selected display field, e.g. having a column with the TCP sequence number. - UlfLamping
Make "Coloring rules" dialog similar to "Display Filters" or "Capture Filters" - instead "edit" button, just merge "Edit Color Filter" dialog to "Coloring rules" dialog. Or at least add "Clone" button to "Coloring rules" dialog.
Add "Prepare a Coloring Rule" to context menu, similar to "Apply as Filter" and "Prepare a Filter".
Wireshark keeps a history of last used display filters. Add a "Previous", "Next" buttons next to "Clear", "Apply".
Show in the GUI that text has been truncated (Olivier Biot). The CList labels used throughout the Wireshark UI will truncate a text entry once it exceeds a given defined, constant length. Wireshark currently doesn't show the user that data was truncated. Maybe we could display a marker like "..." or "[TRUNCATED]" in the event of label truncation.
Add support, in the GTK+ 2.x version, for GTK+'s accessibility support; see the GNOME Accessibility Project. This might involve wrapping various GTK+ GUI operations inside higher-level routines that do the right ATK stuff for GTK+ 2.x and ignore the extra accessibility information in GTK+ 1.2[.x].
Add the ability to view time of day timestamps in GMT (UTC) instead of local time e.g. View -> Time Display Format -> Local Time (checked by default)
Ability to switch between marked packets with hotkeys like in VisualStudio. You mark several packets, and then you can activate a hot-key to switch between each packet. R. Liebscher
The ability to open/process multiple captures at the same time. From a UI standpoint, this could potentially be implemented using a tabbed multi-window interface (particularly since everyone seems to agree that non-tabbed MDI is a very, very bad idea). (I'm not sure I'd even like tabbed MDI. Note that if we do a native Aqua version, we'd definitely want multiple independent windows there. Implementing this is a lot of work, as we'd need to support per-file dissector data structures such as hash tables, as well as per-file dissector preference settings. We'd also want to stop using g_malloc(), because having multiple files open increases the risk of running out of memory - and crashing because you have too many open files isn't very user-friendly. -Guy Harris) It could also be nice that this also introduces a feature "set time reference for all tabs in this window" so all times should be relative to the selected packet in that particular tab/file.
Along with the previous item in the list, allow multiple "views" of the same capture - i.e. allow Wireshark to build multiple windows containing the packet list using various display filters. This could also be implemented using a tabbed multi-window interface (or better yet, allow the user the option of displaying windows (including statistics windows, perhaps?) in a tabbed view, or as individual, separate windows. It would also be useful to have an "Apply filter in new tab" button so that the user can easily switch between viewing the entire capture and viewing various filters of it.
In "live capture" add the display of the current time to the GUI (same format as in the packet view, so "since beginning of capture/first packet" should be possible) - Ian Hubbertz (Does "same format as in the packet view" mean that it should display the current time or date/time, the amount of time the capture has been running, or the amount of time since the last packet was captured, based on the packet view? -Guy Harris)
Have the ability to show/mark the "diff" of two captures. This could be done by highlighting only the fields that are different in the other trace. This feature would help NAT debugging a lot. - Ian Hubbertz
In the 'Follow TCP Stream' window it would be nice if packet boundaries were shown, maybe by a thin separator line between the text lines? This is especially relevant in the 'Hex Dump' view but also in the other views. At present it does start a new line for new packets but if packets are a multiple of 16 bytes long you can't tell when it happens. - Paul Scott
If I use the display filter 'data contains <whatever>' then in the 'Packet Bytes' window for displayed packets the matching bytes should be highlighted - Paul Scott
Ability to select an arbitrary block of bytes, apply encodings / decodings and to export / view the results.
- Can be considered as three layers that can be "piped" together:
  - Add ability to select bytes; this includes existing "selected bytes" based on packet details pane, free byte selection using the bytes pane, selecting a group of bytes in the TCP stream window
  - Add functionality for registering encodings / decodings (e.g. Base64, zip)
  - Add functionality for registering viewers / exporters
  There could be a general purpose "power user" dialog that allowed the user to select from all registered encodings / exports, and "intelligent" shortcuts e.g. when looking at mail in TCP Stream where Wireshark could show a list of attached files, knowing that they were Base64 encoded. See discussion and requested enhancement:
  http://www.wireshark.org/lists/wireshark-dev/200701/msg02918.html http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1084 - Doug Pratley

Name resolution

External data files for hosts, arp, etc.
- (Is this the same as NetMon's "Load/Save Addresses" functionality or something different? - Bryan Miller)
- (If by "hosts" they meant "IP addresses and names", and by "ARP" they meant "MAC addresses and names", then it's similar to the NetMon feature in question, although we'd probably support saving both in a native Wireshark format with all address types or saving in "native" UNIX file formats such as /etc/hosts and /etc/ethers format for particular address types. - Guy Harris)
- (As we have the hosts file now and the manuf/ethers file a while, should we move this to the Done section? - Ulf Lamping)
- (No, as we probably want the ability to have non-IP, non-MAC addresses as well, e.g. Fibre Channel addresses so that we can, for example, have a global file with well-known Fibre Channel addresses - e.g., the addresses from the unused "fc_wka_vals" table in packet-fc.c - and let people add in FC addresses for particular hosts either in the global file or a personal file. The personal files will be even more useful with an "edit address list" GUI; that's an item in the GUI section. -Guy Harris)
- (NIC manufacturer decoding doesn't always work in current versions. Sometimes IP is displayed instead manufacturer's name).
- (By "IP is displayed", do you mean an IP address is displayed, or that a host name corresponding to the MAC address, based on MAC address->IP address from an ARP packet and IP address->host name from IP address resolution? - Guy Harris)
- (Whatever. I can't determine manufacturer of NIC when analyzing some kinds of packets. Those MACs are perfectly resolvable.)
It might be useful to add NetBIOS name resolution to ADNS, or create a library similar to ADNS that supports NetBIOS name resolution. That way, NetBIOS name resolution would work under Windows when asynchronous host name resolution was enabled, and it would be available on non-Windows platforms as well. - Gerald Combs

Dissection

Run-time configuration of tunnelling protocols -- display tunnelled protocol as data or as a full-fledged protocol (which subtree do we put it under?).
Run-time configuration of protocol registration. Currently, the ports, protocols, and types used to determine which dissectors get called are hard-coded. This information should be placed in a configuration file and read at run-time. This would provide run-time setting of protocol "chaining" (i.e., UDP port X calls dissector Y). We have the dissector tables - this'd be a mechanism to tweak them at run time. Some dissectors have preferences to set the port or ports they use, which provides that for those dissectors. (Having all dissectors register themselves by name, rather than anonymously, would be part of this, as you could then have the file say something such as
- sua.ssn 5-12 tcap
-Guy Harris)
Solve dissector security problems once and for all; make dissectors able to run in a seccomp jail. (Well, seccomp seems to be linux only, but Wireshark is a multiplatform program, so this won't help a lot. There are some early thoughts about adding privilege separation, but doing this isn't as easy as it seems, e.g. keeping performance in a reasonable way or being able to save dissector data or ..., see Development/PrivilegeSeparation - UlfLamping)
Enhance 'Decode As' to be able to link specific MPLS labels to specific dissectors. Since the encap inside an MPLS frame is signalled separately, this is probably the only reasonable way to decode things like PPP, ATM, FR over MPLS. (The common cases of Ethernet, IP over MPLS seem to be handled be heuristics.)
Add a "How-To" for compiling a dissector in Windows - Visual Studio 6/.NET
Add MPLS PWE3 Control Word decoding as defined in rfc4385. Basic idea is: if the first nibble following the 'bottom of stack' mpls header is eqaual to 0, then this is PWE3 Control Word. If the nibble equals 4, then ipv4 packet. If the nibble equals 6, then ipv6 packet.
Add a user scriptable language or perhaps an XML user customizable template to describe a packet format. The script language or XML file would then be interpreted by something in Wireshark or an addon so that a non-programmer could add a dissector or a protocol/data-link format for simpler protocols. For example, if you have a frame with a 34 byte inserted proprietary header between the Ethernet Frame header and the IP header and don't know or care about its contents, you could describe the header as a 34-byte opaque blob without having to code a new dissector in C. --J Small, reachable via Wireshark User List

Dissector specific

SIP protocol support. (If by "SIP" you mean "Session Initiation Protocol", we've had that for ages. Do you mean some other "SIP" protocol, or do you mean you want certain features added to the existing SIP dissector? -Guy Harris)
Enhanced time reporting options for DHCP.
Completely decode Oracle protocols, e.g. SQL*Net. (A dissector for Oracle TNS exists, but there's still stuff it doesn't dissect.)
Completely decode MS SQL / Sybase protocols (TDS).
Decode IPSEC/IKE information if provided with shared secrets.
Add "aim.screenname" to the AIM dissector.
Decode GSM Abis Interface signaling. (Comment: Supplying a trace would make it easier to get it implemented.-Anders Broman)
Add support for the FLEET protocol. (QNX4).
Add support for the Qnet protocol (QNX6).
ISUP: support for:
- ANSI (T1.113.3) [This has been started in 0.99.2 though it's probably far from complete]
- National variants (any specific ones?)
TDMoIP: Decoding of the TDMoIP control word as described in the TDM over IP draft of PWE3. Additionally they use a modified UDP packet (source port is used as an ID) and data is transported in AAL1 or AAL2 PDUs. TDMoIP defines a packet format for OAM messages. They could be decoded, too. - Tobias Schluer ( tobias@schluer.de )
Add a TCP analysis flag field which would distinguish between packets originating from the client (the machine that initiated the TCP connection by sending SYN) and packets originating from the server. It would be possible to colorize general TCP client/server traffic similar to "Follow TCP stream", and maybe simplify some dissectors. (That would only work if the SYN were seen; "Follow TCP Stream" handles that by considering the IP address and port for the first packet in the conversation to be the "client". - Guy Harris)
Handle the GRE encapsulation type of 0x8881, which appears to encapsulate a raw byte stream, containing PPP in HDLC-like framing, RFC 1662-style; it'd have to strip out the framing and encapsulation, and reassemble PPP packets split across GRE packet boundaries, so there'd probably be a separate "De-encapsulated PPP" tab in the packet data pane for those packets. (Wireshark 0.10.8 has a dissector for that, although it doesn't handle reassembly.)
NMEA (GPS) protocol support (serial com) - Aleksander Boh
Ability to create a packet-format at runtime "packets matching filter x will contain a field called y at bytes 30-32 network order within the UDP payload" using a GUI to create packet formats which can allow debugging of custom protocols without modifying Wireshark
Reassemble fragmented NBDS packets.
Reassemble PPP Multilink.
Update support for DCCP to latest version of specs (1.1). http://www.icir.org/kohler/dcp/ - Ian McDonald imcdnzl@gmail.com - (1.1) isn't a clear version indication, what RFC is this refering to? Info currently found here http://www.read.cs.ucla.edu/dccp/
Could the LDAP dissector use RFC 2252-style syntax specifications (I think OpenLDAP has a bunch of them) to indicate, for example, what values have binary encodings?
Add DSR dissector (Dynamic Source Routing) for mobile ad hoc networks. (Edit: IESG accept it as an Experimental RFC 4728) Information : http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt - Cyril Grepet
Ventrilo protocol support. - Robin Hägg (Obbin_r [AT] hotmail.com)
Skype protocol support. (May take some time to load) - Robin Hägg (Obbin_r [AT] hotmail.com)
Remote Desktop Protocol (RDP) support - Jason DePriest (jrdepriest atsign gmail dot com)
Add support for the IEC 61850 protocol

Analysis

Respond Time for UDP Communication, to get the performance for UDP communication. (How would you define a "response" in UDP, as opposed to defining it in a protocol running atop UDP, such as DNS or some RPC-based protocol? UDP has no notion of a given packet being a response to a packet sent in the other direction, and there's no guarantee that the first packet going from host B to host A following a packet from host A to host B is a response to that packet. -Guy Harris)
I found Trace:Magic(TraceMagic). It analyzes formerly taken traces i.e. from Wireshark or other trace/sniffer tools such as NetMon. It can find out for example:
- DNS Name requests that could not be resolved
- WINS Name requests that could not be resolved
- TTL that was going to 0 (routing-problems)
- retransmissions
- File-Sharing problems (not found / access denied, ...)
- ... and much more
Would that be an idea to implement in Wireshark ? - Juergen Fischer Well, I would guess that most of the things you mention could already get from Wireshark, if you know how to search for it. That's one of the things I've already mention some time before: we need a way to display expert information with Wireshark default settings. - Ulf Lamping Please provide us with more useful sample CaptureFilters and DisplayFilters for the examples mentioned above. - Juergen Fischer
Add application traffic information. Create the possibility to view network traffic at a higher level. From this higher level give the possibility to zoom in on a specific type of network traffic. For example, Wireshark looks at the network traffic and identifies different types of application traffic (smtp, http, netbios, dhcp, dns). So one can select smtp to look at the smtp packets (port 25) that go over the network. Or deselect http, netbios and dhcp and look at all the other traffic that is going over the network. Something like PacketSeeker from Packeteer or ExpandView from Expand Networks.
IO graphs: Different scales for different filters - we may be looking for correlated traffic but of greatly differing densities. - Steve Ward
Better integration between the IO graph and the list. When selecting a packet in the list, the IO graph could scroll to and high-light the measurement that the packet is part of. Vice versa, clicking on a bar in the IO graph could make the list scroll to and select one of the packets (the earliest?) that is part of that bar. This would make it easy to e.g. look for spikes in the IO graph, and then zoom in on the traffic that was part of it, or to look for control messages in the list, and look at the IO graph to see what the traffic in general look like at that time. - Magnus Reftel From 0.99.8 it is possible to click in the IO Graph to select the first or last package in the interval. - StigBjørlykke
Add code to TCP analysis to display for all retransmissions Number of bytes between the retransmitted segments sequence number and the right edge of the window. This will tell us how many bytes from the end of a burst that a packetloss occured and will make it easier to determine the optimal tcp window size to use for when congestion occurs. Also display the time-delta between the retransmitted segment and the last previous data segment in the same direction to show the retransmission timeout values for the session. (ronnie)
Add to TCP sequence graphs text fields that display the time/sequence-number for the cursor/cross-hair position. Also add the ability to put a permanent red cross at the current cursor position and then show the time/sequence delta between the cross and the current cursor position. (ronnie)
Make RTP analysis less audio specific. Currently interpretation of the RTP stream (let alone saving the payload) is audio specific. The audio profiles dictate a certain use of the RTP marker, but the video profiles dictate different rules. This results in errors being flagged which are not there, according to the video profiles. - Jaap Keuter
Ability to Save RTP stream payload forward and backward in separate channels e.g. Left and Right channels of the same file.
Add Lcamtuf's p0f passive OS fingerprint analysis and masquerade detection. Even very limited analysis based on those signatures would be a serious advantage and something unique to GUI network traffic analyzers. http://lcamtuf.coredump.cx/p0f.shtml - Arv
Add a matrix view, like one may found in commercial software like Observer Pro or Packet Analyzer.
The ability to read virus filters like http://www.networkgeneral.com/SnifferFilters_Details.aspx?Type=1 to better identify virus in the wild traffic. - Simone Chemelli
IO graphs - to add stacked graph as the default graph type (or as an option): "graph 1" based on Y axis and each next graph (2-5) based on the top of the previous one, so we can see very clearly different layers of our traffic. Wojtek Kazimierczak

Done

Reassemble:
- IP fragments
- IPv6 fragments
- OSI CLNP segments
- ONC RPC-over-TCP and DCE RPC fragments
- 802.11 fragments
- X.25 packets with M set
- ATP fragments
- EAP/TLS fragments
- Fibre Channel fragments
- Netware NDPS fragments
- NBF fragments
- Fragmented SNA BIUs
- TDS (Sybase/Microsoft SQL Server) fragments
- WTP fragments
and, for many protocols running atop TCP and the SMB pipe protocol, reassemble the data stream and break the resulting stream into higher-level packets.
Put a filter database on the web site / wiki. (See the CaptureFilters and DisplayFilters pages in the Wiki. - Guy Harris)
New SIP field for Display Filter expressions: RPH (Resource Priority Header). I would like to see a SIP field name added to the expression list: Resource Priority Header. A SIP message with RPH present and set to nsep.1 identifies a priority call and I would like to be able to filter for it. This is apparently not ratified in the standards yet. Is anyone working on this? - gkiss@telcordia.com (In Wireshark 0.10.8 and later, "sip.Resource-Priority" is a string field containing the value of a Resource-Priority header. - Guy Harris)
Add support for BitTorrent dissection (both tracker<->peer and peer<->peer). The protocol specifications are available at the official BitTorrent website. (Wireshark 0.10.8 and later have a BitTorrent dissector from Jelmer Vernooij. -Guy Harris) - (Thanks! You guys are the best.)
Put a troubleshooting database on the web site / wiki. (We now have the NetworkTroubleshooting page on the Wiki; hopefully, that's the type of database the person who submitted this item had in mind. - Guy Harris)
Add a history function for the Packet List Pane, so you can jump forward and back in the previously visited packets, just like web browsers do for webpages. This will be really helpful when you jump around (e.g. using the hyperlinks or using find packets) while trying to find the interesting packets. - Ulf Lamping I've implemented that some time ago, available through the Go->Back and Go->Forward menu items. - Ulf Lamping
Add a link from the currently selected protocol (short name) to the corresponding wiki page. This could be a menu item, a context menu item, some sort of icon in the packet details or such. This feature is implemented in the latest sources and will be in the next (post 0.10.9) release. However, this makes it necessary to restructure the protocol related wiki pages. - Ulf Lamping
Win32 (NSIS): detect whether GTK-Wimp has to be installed (GTK2 && Win2K and up).
RTCP XR (RFC3611) will be widely used for VoIP performance reporting. Add support for at least the VoIP Metrics payload. - Alan Clark - added by Nagarjuna Venna
Kerberos version 4 dissector - standard krb4 - from tcpdump (nneul); we have krb5, but not krb4. (Ronnie Sahlberg added a krb4 dissector.)
Win32: Add a silent install option to the setup program. - Hakan Naslund (I don't like the idea of a silent installer and unless someone explains for what this will be really useful, I'll strongly vote against it. - UlfLamping) If you've got a lot of machines to deploy Wireshark on, you can either repackage it (that means some work) or use a silent installer (if available). I'd vote for this. - Ph. Marek After reading the NSIS docs, there is a silent installer option already, use /S - UlfLamping
A viewer for Wireshark-Files. The viewer shall not have the possibility to actually trace or sniff but provide the user with all other Wireshark functions. (Compare to Textronix K1205-viewer.) Just configure Wireshark with "--without-pcap" on UN*X (or Cygwin?) or with WINPCAP_VERSION not defined in config.nmake (commented out) on Windows with MSVC++, and build it that way. If that build fails, report it on bugs.wireshark.org, as it's supposed to work. -Guy Harris
Decryption of SSL/TLS streams. Entering the server private key is the only user-required info. See: http://sourceforge.net/projects/ssldump/ (Support added to the source in 0.99.0 and the Windows installer in 0.99.3 -- GeraldCombs)

Fixed with the 0.10.10 release:

Ability to decode ESP frames that are encrypted with ESP-NULL. Implemented in the same way that AH decodes currently happen. - Phil Kernick

Fixed with the 0.10.11 release:

Display the temporary capture file name while capturing. (Given that the temporary file name has a bunch of random characters in it, would that just be distracting? -Guy Harris) Show the current capture filename in the statusbar. This is also helpful when working with ring buffers. - UlfLamping
Allow "Hide capture info dialog" even if "Update list of packets in real time" is off. Enable this option, although it's not very helpful as you can't see what's going on. - UlfLamping
DIAMETER
- application-id's are wrong, check in http://www.faqs.org/rfcs/rfc3588.html for correct application-id's. Fixed on 2004-10, see http://www.ethereal.com/lists/ethereal-dev/200410/msg00116.html - Olivier Jacques.
Add a Capture→Restart, that stops the current capture and restarts it with the same options. (Implemented under Capture/Clear menu and status bar. - UlfLamping)
A "Clear" button on the toolbar. Pushing this button will empty the current capture file and packet list, as if we stop the current capture and start a new one with same configuration. (In practice, we just want to monitor network traffic repeatedly without saving it. The growing packet list disturbs our observation and reduces performance. So we have to stop and restart capture again and again. - Jeffrey Shen (Implemented under Capture/Restart menu and status bar. - UlfLamping)
Let the "Save As" function ask something like: "The file XXX already exists, do you want to replace it?". - Ulf Lamping
Clean up the context menus of packet list, packet details and packet bytes. Some of the items might be removed (like the display filters) and all menus should be reordered to have the most context relevant features on top. - Ulf Lamping
Update the GUI in realtime when using Multiple Files. When in this mode, you don't really know what is happening on the interface you are capturing on. What is limiting the GUI from doing this update? (Hmmm, first hiding the capture info dialog and then complain to see nothing on the screen?!? The task model of the capture engine prevents this update. Problem: Which file should be shown, if files changes quickly in ringbuffer mode, as the capturing shouldn't be delayed at file switching? - Ulf Lamping)
Provide some simple "Next File" or "Previous File" mechanism to easily go from one file of a multiple file capture to the next. There should be sufficient information based on the index and timestamp attached to each of the files that this should be possible. (This is now available in the "File->File Set" menu item. - Ulf Lamping)
Add support for BACnet/IP and BACnet/Ethernet protocol (note: BACnet/IP and BACnet/Ethernet are supported in the current version. However, the APDU portion of the frames are not decoded) - Completed item starting in Ethereal 0.10.11 by Steve Karg, Herbert Lischka, and David Richards.

Fixed with the 0.10.12 release:

Provide some basic example files for capture/display filters and coloring rules while installing. - Ulf Lamping (But don't necessarily make those coloring rules the default ones - at least currently, coloring the display significantly slows down the process of loading a capture file, as the colors are computed when a row is put into the packet list, rather than when the row is displayed, so a protocol tree has to be built for each packet in the file. Also, we might want to provide multiple coloring rules files - not everybody would necessarily want the same rules. - Guy Harris)
Make TCP sequence graph windows use the tap system to read the data instead of directly reading from a file. (ronnie)
Win32 (NSIS): Integrate WinPcap installer into Wireshark's main installer to have "all in one place". This might be just to copy the WinPcap installer exe to c:\program files\Wireshark and call that installer when Wireshark's main installer finishes. - Ulf Lamping (How does that installer handle a system that already has WinPcap installed? We probably want an installer that just says "it's already installed" in that case, so we don't overwrite an existing installation - or install a second copy if the already-installed copy isn't installed in the standard location. -Guy Harris)
Win32 (NSIS): Move environment settings (desktop icon, ...) to a separate page, as they should not be part of the "Choose Components" page and this page already has too much settings now. These env. settings just don't belong there (I personally wouldn't expect a desktop icon setting in the choose components page). - Ulf Lamping
Add support for XCAP Protocol,( Only by adding it to XML dissection).
Add support for MSRP protocol.

Fixed with the 0.10.13 release:

I wish that I could specify a precision for timestamps. Working with VoIP traffic e.g. RTP, I am interested only in milliseconds, not in microseconds. Displaying the timestamps (or deltas, etc.) in terms of milliseconds would help. - Zooko
Ability to "Save Payload" for codecs other than G.711u/a. (Note that saving some codecs as anything other than raw data in rtpdump format might have problems due to patents on those codecs. Is there some reason why we have two separate mechanisms for saving RTP traffic, one for those codecs and one for raw rtpdump format? -Guy Harris)(PCM u-law and A-law stream can be saved in au file, payloads with other codecs can be saved raw. Saving in rtpdump format stores payloads with corresponding timestamps, au and raw files are padded with silence samples. -Jaap Keuter)

Fixed with the 0.10.14 release:

When loading a large capture, if you click stop/cancel during the load Wireshark will discard all loaded packets. It would be nicer if this works more similar to when capturing packets and clicking stop if Wireshark were to just abort loading the capture but still retain all the processed pacekts in the list. I.e. when i click stop after loading the first 200000 packets of a huge capture, Wireshark will stop loading it but only show those 200000 packets in the packetlist. (ronnie)
Wireshark command line: to quote Guy: support "-D", but, just as with "-v", we might want to suppress GUI stuff, such as the splash screen, as those options would just print stuff and quit. We should also support numerical interface IDs in Wireshark's "-i" flag, as TShark does, so you don't have to type the ugly name. - UlfLamping Implemented in 16787 - UlfLamping

Fixed post 0.10.14:

The GTK1 UI wordwraps assembled TCP streams, the GTK2 UI doesn't, but should also. Not wrapping makes reading any protocol that lacks linebreaks virtually impossible (XML, etc.) as it all ends up on one line. I'm tired of having to install the GTK1 UI :P - Steven Brown
Have the window open on the same monitor as previous session with dual-monitor display (Currently ALWAYS opens on secondary monitor - Windows version) Chris Welsh (Is this still true for 0.10.9? The GTK library was improved for dual-monitor display output. BTW: move this to the KnownBugs page? - Ulf Lamping) (Filed as bug 887 and solved in revision 18059 - JaapKeuter)

Fixed post 0.99:

Rework TCP reassembly to piggy back on the TCP analysis feature so that we can get reassembly to work even for out-of-order packets. (ronnie)
Display somewhere the name of the rule that set the color for a given packet - perhaps in a tooltip, or in a column. - I've done this as two generated fields in the frame dissector - UlfLamping
Add "coloring rule legend" window or box to the main window. This colouring rule legend will be composed of the colour and the filter name, as in "Coloring rules" dialog box. The filter string is not needed. -Olivier Jacques - Duplicate to above - UlfLamping

Fixed post 0.99.3:

Rework TCP reassembly so a protocol can request "Reassemble all segments until the next FIN/RST. This would help for several protocols atop HTTP which never specify content-length and just contain a single PDU which spans to the end of the session. (ronnie)
Add support for image/png (.png files) media type. This type is often used in webpages. - UlfLamping
Add dissection of the missing secure DNS authentication blobs.
Ethernet Powerlink support.http://www.ethernet-powerlink.org.
While saving, Win32 applications will usually automatically extend a filename by the "usual" extension (e.g. file -> file.pcap). You can later open the file by a doubleclick on it in the Explorer. Our current save dialogs won't add such an extension. OpenOffice has a function called "Automatic filenameextension" in it's save dialog, which will append the appropriate extension if none is given, which seems to be a good solution to me. UlfLamping (Note that ".cap" is probably not a good choice for the extension, given that more than one analyzer program - Windows Sniffer, Microsoft Network Monitor, and, I think, Finisar's Surveyor, and maybe more - use it for their different capture file formats. ".pcap" is commonly used for libpcap files. -Guy Harris) (Note also that Mac OS X also tends to be suffix-oriented; the free-software desktops for UN*X tend to be less suffix-oriented, with a file type identification based on logic similar to the "file" command, involving looking at the file's magic number; doing that would require a MIME type for libpcap files, as the free-software desktops' file typing tends to use MIME types. -Guy Harris)
The "Follow TCP Stream" window should support text search, e.g. a "Find" dialog.
A scripting language, so that some intelligence can be applied to discovering problems. $/!\$ coming soon: Lua

Fixed with the 0.99.5 and/or 0.99.6 release

An option to display a selected packet in plain text format so to allow copy and paste. Possibility to right click on packet and select "View as Plain Text" and a new window will open displaying the text. Same format as the Export as plain text would be usefull. BrokenArrows (cmf16 at hotmail dot com) (If you want copy and paste, ask for copy and paste - having to pop up another window for that is a bit ugly. You should just be able to select some or all of the items in the detail pane and use Edit/Copy or Control-C; see the items above for Edit/Copy. -Guy Harris)
Add support for the (proprietary) 'access-point provisioning protocol' TAPA from Trapeze Networks.

Fixed with the 0.99.7 release

Add support for Q.SIG. The Q.SIG documentation pages can be found at http://www.ecma-international.org/publications/standards/Standard.htm.
Add support for the DPNSS/DASS 2 extensions to IUA; see the draft at the SIGTRAN site. DPNSS will be available in 0.99.7. The DASS2 spec is not publically available.

Fixed in the upcoming 0.99.8

Support multiple "profiles" per user, where a "profile" would include preference settings, coloring rules, display and capture filters, disabled protocols, name <-> address lists, etc.. See this mail message and the followups for more details. (A profile might be implemented as a subdirectory of the top-level preferences directory, with the appropriate files.) - This has been implemented as "Configuration Profiles" - StigBjørlykke
IO graphs - to add a possibility to export the graph's data to csv format for postprocessing. - Milos Ulicny
Warn the user if he enters something like "ip.addr != 1.2.3.4" for combined fields (ip.addr, tcp.port, udp.port, ether.addr, ...). The results will almost certainly not what the user expects. - UlfLamping
Improve statistics and endpoints analysis to support filters (based on display filtered datas). It is needed for huge capture. Up to now the workaround I found is to load datas, set a display filter, save to a file only the displayed datas, open this file and do my analysis ... (At least some statistics do support filters, so presumably this means add support for them to other statistics - or perhaps also add a checkbox for "limit to displayed data" or something such as that, so that you just click that box to use the current display filter as the filter. -Guy Harris) (Right a button "limit to displayed data" would be perfect! In fact i especialy need this for endpoints and conversation.) - This has been implemented as a "Limit to display filter" option in Conversations and Endpoints - StigBjørlykke

Rejected

Enable Capture→Start, even if a capture is in progress. It should just stop the current capture (this just doesn't make sense. Why should a capture stop if you press start?!? That's what "Stop" is for... - Ulf Lamping). (Having Capture→Start only stop the current capture would, indeed, be completely bogus. If he meant that it should stop the current capture and throw out the captured data and start a new capture, that might be useful, but I'd call it Capture→Restart, not Capture→Start. -Guy Harris) (We'll, I actually called it Capture→Restart some time ago and implemented it already then. That's the reason I moved it to the Rejected section. - UlfLamping)
The installer should first check free disk space to avoid bizarre bugs afterwards. (Encountered using a RAM disk of 32 MB as TEMP/TMP directory under Windows.) - Jean-Marc Gillet This is a bug in the NSIS installer, please inform the NSIS people about it. - UlfLamping
The ability to compare packets. (What does "compare" mean here? -Guy Harris) What I would like to see is the ability to highlight a packet and open in a new window- so that if you did this on two or more packets, you could put the windows side-by-side to compare them - John Bullock That feature is available for a long time "View/Show Packet in new window" - UlfLamping
Ability to decode all packets from UDP to RTP in one step. (What does that mean? Does it really mean "ability to recognize RTP packets without seeing setup packets"? If so, there's a heuristic RTP dissector now, although it's not enabled by default - you have to enable it in the preferences.)

Discussion

Do we want to split this page into several subpages of the topics? Editing becomes uncomfortable as the page is very long. - Ulf Lamping

That sounds like a great idea, after reading a lot of this, a more organized version would be better. I mainly came here interested in Wireshark for Windows Mobile 2003. Now that would be awesome. I'm not sure of what help I would be, not knowing any programing language. :-/ I am interested tho. One can always learn. - Win Nadeau ( win.nadeau@gmail.com )

Would it be useful to have a real, honest-to-goodness bug tracker for Wireshark? There's an existing one on our SourceForge project page, but it isn't actively monitored. We could use that, or I'd be willing to install a bug tracker on the Wireshark server instead. - Gerald Combs

Hmmm, unsure about that. I've had a look at the sourceforge bugtracker, and I'm unsure if it's flexible enough for us (e.g. usually I have a field required to fill in the programs version related to that bug/patch/...). However, I did'nt used sourceforge bugtracker nor any other open source bugtracker actively before. If we want to use a bugtracking system (whichever we'd choose), we should handle the categories at least for: Bugs/Support/Patches/Feature Requests somehow like the current sourceforge thing does (not only for bugtracking). - Ulf Lamping

I've added a declined section, or should we simply remove these items? This problem will become obsolete, if bug tracker is up. - UlfLamping

The bug tracker's up. Should we move the wishlist items to the bug tracker? (And what about the development wishlist?) - Guy Harris

The current state the bug tracker is, makes me feel that we shouldn't do this. E.g. we don't have any real Components to choose from (putting it all under "Wireshark" would become a mess IMO). - UlfLamping

CategoryCategory CategoryHomepage