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
We should deprecate the use of hidden fields, at least for fields that arei
useful in filters. To make it easier for users to discover and use the fields.
Change the highly useful field for TCP segment payload length from
being a hidden field to be a generated field instead.
svn path=/trunk/; revision=50112
Add tcp.analysis.spurious_retransmission. Although RFC 793 does not define
spurious TCP retransmissions, TCP spurious retransmissions are referenced in
other RFCs and research.
svn path=/trunk/; revision=49160