Add menu items for each corresponding item in gtk/main_menubar.c that
calls gtk_stats_tree_cb(). Hopefully that's everything. Note that we use
quite a bit less code than the GTK+ flavor and why we might not want to
do that. Change a few things in ui/qt/CMakeLists.txt to more closely
match the GTK+ version. Add plumbing for tap registrations in
CMakeLists.txt and Makefile.am. Add the ability to copy text as CSV or
YAML.
svn path=/trunk/; revision=53464
Based on attachment #12139 (diff for adding the table) by rtsking117,
but keep original formatting and encoding (ASCII).
svn path=/trunk/; revision=53457
Specifically, proto_tree_add_expert() must take an actual tree node (for example
from proto_item_add_subtree()) and cannot take just any old item node. The
original intent (before the conversion) appeared to be just to put it on the
tree, so do that.
Another assertion gone from
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9406
svn path=/trunk/; revision=53456
handle that file not ending with a 2-byte 0xffff end-of-file record.
This fixes bug 9455, although it doesn't add support for reading an
"index" file for a capture that's in multiple .rf5 files, which is a
separate issue noted in that bug.
It also doesn't attempt to figure out what the data in the new record
type following the data that appears to be the same as that in the other
data record format but preceding the actual packet data is.
svn path=/trunk/; revision=53452
in a source description record, including the stack. Dump some other
fields in those records as well.
Attach separate sequential and random read buffers to the private data
structure, rather than allocating them in various routines (and not
always freeing them) and, in at least one case, allocating a single
*common* buffer for all wth's to use.
Fix some comments (the DS0 mask is 32 bytes long, but gets turned into a
bitmask).
Put in a description of what a "stack file"'s contents look like. Much
of it may be useless to us (for example, we have the notion that TCP has
protocol number 6 built-in...), but the RELATION entries that map from
"BASE" to a protocol could obviate the need to have the user specify a
map from stack file names to starting protocols, and we might be able to
use, for example, entries that map TCP/UDP/SCTP port numbers to
protocols to obviate the need for the user to explicitly use Decode As
or otherwise configure port-to-protocol mappings themselves.
Add a bunch of record length checks before we fetch data from records.
svn path=/trunk/; revision=53450
The basic idea behind this design is to have dissectors register with a "decode as list" with their name and dissector table. When "Decode As" dialog is launched, any "registered" dissector found in the packet will cause a tab to be created in the dialog. Any GUI (GTK+/Qt/tshark) can just hook into the "decode as list" to see what can be provided.
This patch includes the GUI portion of the functionality (including packet-dcerpc.[ch] because it had some GUI dependencies that are now removed).
Other notes:
1. Some "GUI text" (UTF8_LEFTWARDS_ARROW and similar) made their way into the dissector code. Not sure how necessary it is and if reformatting the strings to avoid the macros is desired (TCP/UDP use it, SCTP doesn't).
2. I converted the SCTP functionality to have 2 tabs (instead of radio button), currently both are labeled "Transport" which could be confusing to users. Naming suggestions welcome (as well as for naming of tabs from other dissectors).
3. BER and DCERPC have more opportunity to use Decode As now that they are selected based on dissector presense, not packet_info values.
4. Catapult DCT2000 populates pinfo->ipproto, yet under new design will not show up to do Decode As. Should a "decode as item" be created for it?
5. BER dissector doesn't have Clear/Show Current functionality working (never did)
6. Bluetooth (in old design) could have been used "capture wide" instead of single packet (creating tabs of values not present in current packet), which goes against what I believe to be in the intent of Decode As, but I'm willing to hear counter-arguments.
svn path=/trunk/; revision=53446
The basic idea behind this design is to have dissectors register with a "decode as list" with their name and dissector table. When "Decode As" dialog is launched, any "registered" dissector found in the packet will cause a tab to be created in the dialog.
This patch includes just the dissector portion of the functionality (minus packet-dcerpc.[ch] because it has hooks to the current GUI)
svn path=/trunk/; revision=53445
The main driving force for this was my new Decode As functionality (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9450) that wants a dissector/subdissector table relationship for all dissectors wanting to use Decode As functionality. The ethertype() function provides the value to the "ethertype" subdissector table, so I think it should be matched to a dissector. Only odd side effect is the display filter of "ethertype" returns no packets because there is no "item" associated with the dissector.
svn path=/trunk/; revision=53443
Dump the raw contents of records as hex and ASCII, not just hex.
Sort the record types, and add a new one for a type we've seen in a k18
file and about which we know nothing.
For unknown record types, print the type in hex.
svn path=/trunk/; revision=53441
configuration file directory and directory in which to save captures),
have the routine to parse -P options use them, and move that routine to
libui.
Have that routine just return a gboolean.
svn path=/trunk/; revision=53435
/usr/include/qt5/QtCore/qglobal.h:1079:4: error:
"You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC or -fPIE."
svn path=/trunk/; revision=53432
Add support for new PostgreSQL (9.3) error/notice message fields
Improves the PostgreSQL protocol dissector by adding support for the new error and notice fields which are new in PG 9.3:
http://www.postgresql.org/docs/9.3/interactive/protocol-error-fields.html
In particular, it adds support for the 'p', 'q', 's', 't', 'c', 'd', and 'n' field codes.
From me :
Fix wrong hf name...
svn path=/trunk/; revision=53431
Change the "Raw" character type to UTF-8. I'm not sure it's possible
to show true raw data in a QTextEdit widget and calling it UTF-8 more
accurately repesents what happens when you pass a char * to a QString.
Add a YAML display. Hopefully Scapy users will find it useful.
Sort the the character display items alphabetically. Make sure we go
back to the top of the buffer when we change the direction or character
set. Be less aggressive about setting focus on the "find text" entry.
svn path=/trunk/; revision=53421
Stig Bjørlykke