This is more reliable than doing "tree math" and corrects the intention of 5470356154 which made the incorrect assumption that tcp_dissect_pdus will be called with the tree that is passed into a protocol's main dissection function (directly from TCP).
Change-Id: I6ffc2188420ab74784c7bc2c69aa79ff071c90b6
Reviewed-on: https://code.wireshark.org/review/1214
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add ep_ to routines that may return ephemeral strings.
Change "get_XXX" to "XXX_to_display" if the routine returns a formatted
string if it can't get a name.
Change-Id: Ia0e82784349752cf4285bf82788316c9588fdd88
Reviewed-on: https://code.wireshark.org/review/1217
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, the right protocol gets shown for exceptions in PDUs after the
one for which dissection failed.
Change-Id: I9f212fe55f19a7a818cd58cd0611683cbb723c0c
Reviewed-on: https://code.wireshark.org/review/1189
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I coincidentally found a few files with errors, so I thought it might be time to run it on the whole directory again.
Change-Id: Ia32e54b3b1b94e5a418ed758ea79807c8bc7e798
Reviewed-on: https://code.wireshark.org/review/978
Reviewed-by: Michael Mann <mmann78@netscape.net>
Create a placeholder protocol tree item under which to put the options,
do the analysis of fields from the fixed-length portion of the TCP
header (such as sequence numbers), and then do a straightforward
dissection of the options, throwing an exception if we run past the end
of the options field.
This is a bit simpler, and doesn't add confusing notes about
truncation of the options.
XXX - we're currently not including selective acknowledgments in any of
the SEQ/ACK analysis; should we? That means, of course, that we have to
dissect the options before doing that analysis, and if the options were
cut short by slicing, you lose....
Change-Id: I425a6c83f26512b802267f76739cbf40121b3040
Reviewed-on: https://code.wireshark.org/review/511
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The OP asked 9169 to be reopened because the capture was spewing ~40GB of output
when dissected with tshark. Investigation showed this was because the HTTP
dissector was requesting ONE_MORE_PACKET reassembly a lot, and TCP was adding
each step as a data-source which was being printed by tshark's hex dump. This
was leading to O(n^2) of output.
To fix, introduce function remove_last_data_source which removes the most recent
data source from the list. If the subdissector in TCP reassembly asks for
ONE_MORE_PACKET, assume it hasn't added any tree items (since it shouldn't have)
and remove the data source since it is unnecessary.
This may break dissectors which add tree items and *then* return
ONE_MORE_PACKET, since they will have their data source removed out from under
them. I believe those cases should be fixed to not add tree items until they're
sure they have enough data.
Change-Id: Iff07f959b8b8bd1acda9bff03f7c8684901ba8aa
Reviewed-on: https://code.wireshark.org/review/38
Reviewed-by: Evan Huus <eapache@gmail.com>
Tested-by: Evan Huus <eapache@gmail.com>
Rename the 2nd SCTP Transport tab to "SCTP(PPID)" to make it obvious what it
is.
Fix up casing and code formatting in both SCTP and TCP Decode-As code.
svn path=/trunk/; revision=54391
I'm not sold on the name or module the proto_data functions live in, but I believe the function arguments are solid and gives us the most flexibility for the future. And search/replace of a function name is easy enough to do.
The big driving force for getting this in sooner rather than later is the saved memory on ethernet packets (and IP packets soon), that used to have file_scope() proto data when all it needed was packet_scope() data (technically packet_info->pool scoped), strictly for Decode As.
All dissectors that use p_add_proto_data() only for Decode As functionality have been converted to using packet_scope(). All other dissectors were converted to using file_scope() which was the original scope for "proto" data.
svn path=/trunk/; revision=53520
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
Collect packet numbers when following streams so that we can correlate
text positions with packets. Add a FollowStreamText class so that we can
track mouse events. Add a hint label that shows the packet under the
cursor along with packet counts and the number of "turns".
Add the packet number to the C array dump. Note that dumping to YAML
might be useful for Scapy users.
svn path=/trunk/; revision=53314
dissector_try_uint to dissector_try_uint_new: protocols called due to TCP port
matching were not getting added to the list of protocols in the frame. The
"add_proto_name" parameter should be TRUE except in unusual circumstances.
svn path=/trunk/; revision=53308
All dissectors that call tcp_dissect_pdus() have the same relative tree position, so it doesn't need to be specifically saved in the packet_info.
svn path=/trunk/; revision=53253
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
protocol IDs. This is substantially more efficient, which means we can build it
all the time rather than only if tree (in my benchmarks the extra time taken is
not large enough to be statistically significant even over tens of thousands of
packets).
This fixes what was probably a bug in btobex that relied on layer_names for
non-tree dissection. It also enables a much simpler fix for
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9303
svn path=/trunk/; revision=53089
- when the text parameter is constant col_add_str() and col_set_str() are equivalent but col_set_str() is faster.
- same for replace col_append_fstr and col_append_str
- remove col_clear() when it's redundant:
+ before a col_set/col_add if the dissector can't throw an exception.
- replace col_append() after a col_clear() with faster col_add... or col_set
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9344
svn path=/trunk/; revision=52948
Patch was tested with snaplens of:
49 and 52: (TCP fixed header incomplete) TCP analysis NOT performed.
54: (Fixed header complete but entire options wfield was sliced off) TCP analysis ran and was OK.
64: (Fixed header complete but a portion of the options field was missing) Options were dissected to the extent possible. TCP analysis ran and was OK.
66: (Fixed header and options complete) TCP analysis ran and was OK.
70: (Fixed header and options complete plus 4 bytes) TCP analysis ran and was OK.
svn path=/trunk/; revision=52467
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
Add get_tcp_stream_count() to the TCP dissector and modify
graph_segment_list_get() to allow matching based solely on a stream.
Use text instead of icons for the mouse click behavior buttons. Remove
their PNG resources since we aren't using them any more. Fix setting the
cursor in the graph widget.
svn path=/trunk/; revision=51989
Speaking of r51356, a clarification to its commit message is in order: Initially my intention was to only add the urgent pointer field when the URG bit was set; however, I then noticed that the acknowledgment number field was always being added irrespective of the ACK bit. Had I made the change as I originally intended, it would have introduced an inconsistency. After some deliberation, I opted for consistency, but botched the commit message.
svn path=/trunk/; revision=51431
References:
http://tools.ietf.org/html/rfc793, http://tools.ietf.org/html/rfc1122, ...
http://www.wireshark.org/lists/ethereal-dev/200307/msg00297.html
Similarly, nowhere does it say that the acknowledgment number field must be zero if the ACK bit is not set.
This patch effectively reverts r37721. If non-zero urgent pointers are of interest to you when the URG bit is not set, then a filter such as follows can be used:
(tcp.flags.urg == 0) && !(tcp[18:2] == 00:00)
Similarly, if non-zero acknowledgment numbers are of interest to you when the ACK bit is not set, then use this filter:
(tcp.flags.ack == 0) && !(tcp.ack == 0)
For consistency, should we avoid adding the ack field in this case as well? The above filter would then change to:
(tcp.flags.ack == 0) && !(tcp[8:4] == 00:00:00:00)
This change was prompted by the following question on ask.wireshark.org:
http://ask.wireshark.org/questions/23753/tcp-urgent-pointer-value-not-displayed
svn path=/trunk/; revision=51356
"tcp.analysis.duplicate_ack" has both an hf_ and ei_ "item" so that the duplicate ack # and frame # can be assembled properly in the tree. Since hf_tcp_analysis_duplicate_ack is of type FT_NONE, the duplicative display filter name is okay.
svn path=/trunk/; revision=50302
Michael Mann