be done on flows from one address to another; reassembly for protocols
running atop TCP should be done on flows from one TCP endpoint to
another.
We do this by:
adding "reassembly table" as a data structure;
associating hash tables for both in-progress reassemblies and
completed reassemblies with that data structure (currently, not
all reassemblies use the latter; they might keep completed
reassemblies in the first table);
having functions to create and destroy keys in that table;
offering standard routines for doing address-based and
address-and-port-based flow processing, so that dissectors not
needing their own specialized flow processing can just use them.
This fixes some mis-reassemblies of NIS YPSERV YPALL responses (where
the second YPALL response is processed as if it were a continuation of
a previous response between different endpoints, even though said
response is already reassembled), and also allows the DCE RPC-specific
stuff to be moved out of epan/reassembly.c into the DCE RPC dissector.
svn path=/trunk/; revision=48491
epan/show_exception.c, as it's used outside
epan/dissectors/packet-frame.c. Update their callers to include
<epan/show_exception.h> to get their declaration.
Add a CATCH_NONFATAL_ERRORS macro that catches all exceptions that, if
there's more stuff in the packet to dissect after the dissector call
that threw the exception, doesn't mean you shouldn't go ahead and
dissect that stuff. Use it in all those cases, including ones where
BoundsError was inappropriately being caught (you want those passed up
to the top level, so that the packet is reported as having been cut
short in the capture process).
Add a CATCH_BOUNDS_ERRORS macro that catches all exceptions that
correspond to running past the end of the data for a tvbuff; use it
rather than explicitly catching those exceptions individually, and
rather than just catching all exceptions (the only place that
DissectorError should be caught, for example, is at the top level, so
dissector bugs show up in the protocol tree).
Don't catch and then immediately rethrow exceptions without doing
anything else; just let the exceptions go up to the final catcher.
Use show_exception() to report non-fatal errors, rather than doing it
yourself.
If a dissector is called from Lua, catch all non-fatal errors and use
show_exception() to report them rather than catching only
ReportedBoundsError and adding a proto_malformed item.
Don't catch exceptions when constructing a trailer tvbuff in
packet-ieee8023.c - just construct it after the payload has been
dissected, and let whatever exceptions that throws be handled at the top
level.
Avoid some TRY/CATCH/ENDTRY cases by using checks such as
tvb_bytes_exist() before even looking in the tvbuff.
svn path=/trunk/; revision=47924
-> Delete some unused header fields found with checkhf.pl
-> Fix a couple of typos.
-> Minor whitespace changes.
-> Add a TODO about replacing strstr with either g_strrstr or g_str_has_suffix
svn path=/trunk/; revision=47420
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
This patch provides
i) support for Shared Use of Experimental TCP Options (draft-ietf-tcpm-experimental-options-03)
ii) support for TCP Fast Open (draft-ietf-tcpm-fastopen-02).
A new 'TFO=R' string is appended at the column info in case a client sends a SYN packet with a Fast Open Cookie Request. Moreover, if the server responds with a SYN-ACK containing a Fast Open Cookie option a 'TFO=C' is shown (as well as in any subsequent client attempt to send SYN + DATA).
tcp.options.tfo display filter can be used in order to easily select the complete TFO three-way handshake.
Chrome (and I think also Firefox) has support for client-side TFO. Linux 3.7 got both client and server-side support.
svn path=/trunk/; revision=46723
Allow Raw Data dissector to dissect TCP packets with Riverbed Transparency options if sport dissector (found only in Riverbed) is not found.
#BACKPORT
svn path=/trunk/; revision=46544
number of SACK ranges found in the SACK option.
This involved extending the IP options framework to include an extra
void* data field, which in the case of TCP is filled in with the tap
struct - other users currently pass NULL.
I first implemented the graph to sort the SACK ranges and show (in red)
the unacknowledged regions between them, but this became confusing where
the number of ranges is limited by TCP padding bytes. i.e. you can't
tell how many SACKs could have been encoded, so some of the gaps between
ranges may already have been received.
svn path=/trunk/; revision=46006
The reassembled fragments tree in the Packet Details view is awesome, but it
lacks one thing: a field that exposes the reassembled data.
tcp.data already exists for exposing a single TCP segment's payload as a byte
array. It would be handy to have something similar for a single application
layer PDU when TCP segment reassembly is involved. I propose
tcp.reassembled.data, named and placed after the already existing field
tcp.reassembled.length.
My primary use case for this feature is outputting tcp.reassembled.data with
tshark for further processing with a script.
The attached patch implements this very feature. Because the reassembled
fragment tree code is general purpose, i.e. not specific to just TCP, any
dissector that relies upon it can add a similar field very cheaply. In that
vein I've also implemented ip.reassembled.data and ipv6.reassembled.data, which
expose reassembled fragment data as a single byte stream for IPv4 and IPv6,
respectively. All other protocols that use the reassembly code have been left
alone, other than inserting NULL into their initializer lists for the newly
introduced struct field reassemble.h:fragment_items.hf_reassembled_data.
svn path=/trunk/; revision=44802
Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
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
Guy Harris