Do not let the generated TCP Analysis Flags get all TCP bytes.
Point the hidden TCP Segment Len to the header length byte.
svn path=/trunk/; revision=26806
"tcp.stream", this will make it possible to sort packets by
tcp stream, filter tcp streams exactly, etc.
It is also the preparation for a fix for bug 1447
svn path=/trunk/; revision=26305
flight on a tcp connection.
this is quite useful toghether with io-grapgs to track how much of the
tcp window that an application actually uses
svn path=/trunk/; revision=26067
maybe this will start the first edit war in Wireshark ;-)
As discussed on the dev-list, we might need some sort of profile for the expert output as well ...
for this TCP window stuff - and problably a lot of other stuff - the severity of an expert message will largely depend on your network usage and configuration
svn path=/trunk/; revision=24803
a new conversation. The new conversation was created from
a template conversation with NO_PORT2 set. In this case
the tcp conversation data structure was not initialized
and therefor the scaling options could not be saved in the
conversation.
svn path=/trunk/; revision=24796
capture file that were actually on the wire. The reassembly code waited for
the gaps to be filled in by retransmissions, which would never come.
With this fix all acknowledged data will be output with "[xxx bytes missing in
capture file]" inserted in every gap.
svn path=/trunk/; revision=23878
When doing TCP_SEQ analysis, if the packet is a SYN, then it's
not a lost packet but the tcp ports are being reused. This is often
seen in load-balanced environments where client ports are preserved
on the server-side.
This time it is fixed by creating a new conversation whenever a
new SYN is received for an existing conversation. This fixes the
following:
- bug 1680: Error in TCP Sequence number analysis
- TCP-conversation timestamps for new TCP-sessions with the addresses
and ports as a previous TCP-conversation in the trace-file.
svn path=/trunk/; revision=23299
- if offset is 0, tvb_length is the same as tvb_length_remaining, just faster.
Replace
- col_append_fstr() with faster col_append_str()
- col_add_str() with col_set_str()
when it's safe
svn path=/trunk/; revision=23252
When a SYN/ACK is missing in the capture, the base_seq used in
relative sequence numbers was not set correctly. I made the
setting of fwd->base_seq and rev->base_seq a little more solid.
svn path=/trunk/; revision=23213
- COL_REL_CONV_TIME which is used to display the time relative to the first frame that was seen in the conversation
- COL_DELTA_CONV_TIME which is used to display the delta time from the previous frame of the conversation
It also adds the function "col_set_time()" to "epan/column-utils.[ch]" which can be called from within a dissector to set either of these two columns to the appropiate time.
Last but not least, it lets the tcp-dissector make use of these two columns.
svn path=/trunk/; revision=23058
tcp.time_relative ==> the time that has elapsed since the
first packet that was seen in the current TCP stream
tcp.time_delta ==> the time that has elapsed since the
last packet that was seen in the current TCP stream
Calculating these timestamps is turned off by default to not
use the extra memory that is needed for the per-packet-data.
It can be turned on through the TCP protocol preferences
svn path=/trunk/; revision=22966
not a lost packet but the tcp ports are being reused. This is often
seen in load-balanced environments where client ports are preserved
on the server-side.
We only want to report port reusage once, so the SYN/ACK is excluded
from TCP_SEQ analysis.
svn path=/trunk/; revision=22762
When a subdissector on top of TCP set ... DESEGMENT_UNTIL_FIN ... then
the subdissector should receive the whole reassembled TCP stream in tvb.
But the bug is it is missing the last payload from the FIN packet.
svn path=/trunk/; revision=22578
add a fix for ack/seq tracking when the tcp is broken and sends a
non-zero ack field for SYN packets.
add a warning to the dissect pane that illustrates that these are broken
packets
svn path=/trunk/; revision=22267
Fix for Bug 1136 (TCP Checksum Validation)
TCP cksum 0xffff should not appear in TCP headers. RFC 1624 explains that it
can be generated by a (not-so-good) algorithm for incremental updates to the
tcp-checksum.
New behavior of wireshark when having cksum == 0xffff :
- use "Checksum: 0xffff [should be 0x0000 (See RFC 1624)]" in the
packet-detail pane
- set tcp.checksum_good to FALSE (just like checksum-offload packets)
- set tcp.checksum_bad to FALSE (just like checksum-offload packets)
- Generate an expert warning: "TCP Checksum 0xffff instead of 0x0000 (See RFC 1624)"
- add "[TCP CHECKSUM 0xFFFF]" instead of "[TCP CHECKSUM BAD]" to COL_INFO
svn path=/trunk/; revision=21295
for the quite unusual case when we need to do this multiple times in a row for the same PDU.
This fixes the issue reported by Xiaoguang Liu on the mailinglist
where wireshark did not manage to properly reassemble a big HTTP header spanning several (more than two) tcp segments.
svn path=/trunk/; revision=20179
it broken in one of the previous bugfixes to tcp
add a function to print an emem tree to the console for easier emem tree debugging
svn path=/trunk/; revision=19877
there used to be a bug in tcp reassembly that even if the dissector only asked for x more bytes from the next segment the entire segment would still be added to reassembly.
this caused some issues when there was a new multisegment pdu that started at the end of the segment but this bug was fixed when tcp reassembly was refactored semi-recently.
there was also another "bug" in the http reassembly that it would only ask for one more byte at a time when doing reassembly.
this did work well however when we still had the bug in tcp reassembly but made wireshark become very very very slow once this tcp bug was fixed since it is very very very slow to reassemble a huge http pdu just one byte at a time.
this patch adds partial support (what we need for http which does not use tcp_dissect_pdus() ) for the desegmentation flag : DESEGMENT_ONE_MORE_SEGMENT and also to the http dissector so that reassembly of http headers spanning multiple semgents now become fast again
svn path=/trunk/; revision=19859