visible, we can still configure a scaling factor and therefore get
better TCP sequence analysis and see better stream graphs.
A single preference is used for any/all streams for which the true value
isn't known. I tried to make it obvious when showing the calculated
window size that it came fromt he preference setting. The default value
for this preference is off, i.e. it won't change existing behaviour.
This was discussed a little at Sharkfest and raised on the developers
list last week.
svn path=/trunk/; revision=43686
Also:
- don't use val_to_str_const() with a "format" default string;
- rename 'opt_len_type' enumeration identifiers to be less generic.
svn path=/trunk/; revision=43210
For such protocols, hte state gets out of sync of for example the same PDU is invoked twice in a row, which sometimes can happen if there is tcp retransmission and we see the same PDU twice. First for hte original segment and a second time for the tcp retransmission.
These protocols might lack an easy way to detect that a PDU is seen twice or out of order.
To handle this a little better, offer a TCP option that defaults to being disabled but when enabled skips invoking any subdissector for retransmitted or out of order packets.
(For some virtualization environments it sometimes becomes VERY common to see false tcp retransmissions due to segments being captured twice making this even worse)
We dont want this option to default to ON because for most cases we do want the current behaviour where the subdissector is called twice, or more, for any PDU that is retrasnmitted on the TPC layer.
For example, assume a SMB response packet is retransmitted on the TCP level.
This may result in a capture file that looks like
1 -> SMB request
2 <- SMB response to 1
... 1 second ...
3 <- SMB response to 1 TCP retransmission
For this case we definitely want packet 3 to be passed to the SMB layer so that
the request/respons ematching will detect that the response time for this transaction was > 1.0 second
We want smb.time to indicate the delta betwenn packets 1 and 3
as well as the SMB Service Response Time to indicate that this command took very long.
svn path=/trunk/; revision=42774
ack number to the lookup key (which was previously just the frame number).
This helps with situations where multiple segments of the same TCP
conversation can be found in the same frame in a capture (e.g. with LTE
user-plane traffic carried in logged MAC or RLC frames).
svn path=/trunk/; revision=41788
A corner case was posted to the Q&A site showing incorrect calculation of bytes in flight (http://ask.wireshark.org/questions/8843/bytes-in-flight-problems-with-retransmissions)
The capture in question has a tcp segment (frame 12) that is a retransmission of unacked earlier data (frames 4, 9, 10) and also contains some new data. Eventually an ACK is received for the earlier segments (frame 16) but the code doesn't remove frame 12 from the linked list of unacked segments because it extends past the received ACK. When more data is received in frame 17, the bytes in flight is calculated from the start of frame 12 rather than from the unacked portion of it, leading to a larger incorrect value.
The change simply updates the starting sequence number in the unacked segment list for any partially acked segment to be the start of unacked data.
The capture in question now shows correct information for bytes in flight, and hopefully the nature of the change won't cause issues elsewhere.
svn path=/trunk/; revision=40929
Multipath TCP Option
Extensions for Multipath Operation with Multiple Addresses, as defined in http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-04. I implemented this as a TCP option.
From me :
Remove a subtree
Add Subtype in top of multiPath subtree
svn path=/trunk/; revision=40370
officially listed as "Unassigned", and people might use it for their own
purposes (and, in fact, one bug-submitter was doing so; they probably
should have used 253 or 254, but...). Get rid of the code to dissect
it.
svn path=/trunk/; revision=40075
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
The attachted patch fixes and enhances the SCPS TCP option dissection. Changes
are:
- fix order of reserved Bit 1,2,3
- fix minimum TCP option length
- fix proto items
- add proto item for Connection ID
- removed the verify_scps() function. It's logic was broken, because it did
reset the scps_capable flag on both flows if one of them did not have it.
However sometimes that flag is only enabled in one flow direction and that flow
direction could see TCP options later on, which would get dissected as invalid.
See the attachted capture file for an example.
svn path=/trunk/; revision=38326
Fix :
packet-tcp.c:3337: error: ‘dissect_tcpopt_maxseg’ undeclared here (not in a function)
packet-tcp.c:2264: error: ‘dissec_tcpopt_exp’ defined but not used
svn path=/trunk/; revision=38176
Introduced a new tcp state variable: maxseqtobeacked, this is the
maximum seq number that can be acked by the rev party in normal case.
This new state variable only serves the proper detection of
tcp.analysis.ack_lost_segment indicator, and decouples it from the detection of
tcp.analysis.lost_segment indicator.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6081
svn path=/trunk/; revision=37922
the nonce bit, we should display 3 nibbles on the Flags summary line in order
to represent all flag bits. While arguably we need not worry about reserved
bits, the nonce bit is not currently represented, so that bit alone pushes us
into the next nibble.
svn path=/trunk/; revision=37856
This lets us get rid of the per-frame_data-structure prev and next
pointers, saving memory (at least according to Activity Monitor's report
of the virtual address space size on my Snow Leopard machine, it's a
noticeable saving), and lets us look up frame_data structures by frame
number in O(log2(number of frames)) time rather than O(number of frames)
time. It seems to take more CPU time when reading in the file, but
seems to go from "finished reading in all the packets" to "displaying
the packets" faster and seems to free up the frame_data structures
faster when closing the file.
It *is* doing more copying, currently, as we now don't allocate the
frame_data structure until after the packet has passed the read filter,
so that might account for the additional CPU time.
(Oh, and, for what it's worth, on an LP64 platform, a frame_data
structure is exactly 128 bytes long. However, there's more stuff to
remove, so the power-of-2 size is not guaranteed to remain, and it's not
a power-of-2 size on an ILP32 platform.)
It also means we don't need GLib 2.10 or later for the two-pass mode in
TShark.
It also means some code in the TCP dissector that was checking
pinfo->fd->next to see if it's NULL, in order to see if this is the last
packet in the file, no longer works, but that wasn't guaranteed to work
anyway:
we might be doing a one-pass read through the capture in TShark;
we might be dissecting the frame while we're reading in the
packets for the first time in Wireshark;
we might be doing a live capture in Wireshark;
in which case packets might be prematurely considered "the last packet".
#if 0 the no-longer-working tests, pending figuring out a better way of
doing it.
svn path=/trunk/; revision=36849
In the explanation of TCP Option 78 (Riverbed Transparency), the labels
are "CSH IP Addr/Port" and "SSH IP Addr/Port". This should be "Src SH IP
Addr/Port" and "Dst SH IP Addr/Port".
The filter keys for these labels are correct.
svn path=/trunk/; revision=36667
Martin Mathieson