Right now with DESEGMENT_UNTIL_FIN, the TCP dissector doesn't display the
fragment tree (the "Reassembled TCP segments" with links to the frames that
were reassembled).
Attached is one possible patch to packet-tcp.c to display the fragment tree.
Because DESEGMENT_UNTIL_FIN dissects the FIN packet as the high-level PDU, the
fragment tree also contains the FIN packet. It has 0 bytes of PDU data. Ugly but logical..
svn path=/trunk/; revision=28090
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
Jaap Keuter