In most cases you can use the default Wireshark parameters for TCP and UDP network analysis, but there are also some changes that can be configured. The changes will be configured in the Preferences window.
For TCP or UDP configuration:
In this section we will see how to configure TCP and UDP preferences.
Let's see some parameters that can influence the capture of UDP:
You can configure the following parameters in UDP:
- Show UDP summary in protocol tree: Mark this button if you want the UDP summary line to be shown in the protocol tree (set by default)
- Try heuristic sub-dissectors first: Try to decode a packet using the heuristic method before using a sub-dissector registered to the specific port
- Validate the UDP checksum if possible: Validates the UDP checksum
- Collect process flow information: Collects process flow information
By default only the first parameter is set. In most cases it is enough.
You can configure the following parameters in TCP:
- Show TCP summary in protocol tree: Mark this button if you want the TCP summary line to be shown in the protocol tree (set by default).
- Validate the TCP checksum if possible: This feature can slow down performance. In most cases it is not required.
- Allow subdissector to reassemble TCP streams: This option is for stream analysis (set by default).
- Analyze TCP sequence numbers: When this is set, Wireshark analyzes sequence numbers and track phenomena such as retransmission, duplicate ACKs, and so on, which is one of the important features of Wireshark.
- Relative sequence numbers: When this is set, Wireshark will show you every TCP connection that starts from
Seq=0. - Track number of bytes in flight: This setting enables Wireshark to track the number of unacknowledged bytes flowing on the network (set by default).
- Calculate conversation timestamps: This feature enables the calculations of TCP timestamps option.
- Try heuristic sub-dissectors first: Try to decode a packet using heuristic method before using a sub-dissector registered to the specific port.
- Ignore TCP Timestamps in summary: Ignore the timestamp option in the TCP header.
- Do not call subdissector for error packets: This option does not analyze erroneous TCP packets.
There are some parameters in the TCP preferences that I would like to say a few words about.
Referring to relative sequence numbers, when you look at a TCP connection you see that it always starts with sequence numbers equal to zero. These are the relative numbers that are normalized to zero by Wireshark. The real numbers are numbers between 0 and 232, picked by the TCP process, which are difficult to follow. The TCP standard does not set any rule for picking this number.
The calculating conversations timestamps refers to the timestamp option of the TCP packet. The TCP timestamps option carries two 4-byte timestamp fields, as seen in the next diagram:
The problem that the timestamp option comes to solve is the sensitivity of TCP to delay variations. The solution, and written in RFC 1323, is to use TCP options in the following ways (for every TCP connection):
- The sender places a timestamp in each data segment that it sends (the Tsval field)
- The receiver reflects these timestamps in ACK segments (the Tsecr field)
Then, a single subtraction gives the sender an accurate RTT measurement for every ACK segment (which will correspond to every other data segment, with a sensible receiver). This mechanism is called Round Trip Time Measurement (RTTM).
UDP is a very simple protocol with a very simple header that includes only four fields: source port, destination port, packet length, and checksum. Checksum is used by the receiver to check whether to accept the packet or drop it. In case of a packet drop, there is no recovery mechanism. In some cases, the application will recover it (for example, DNS that sends the request again), and in some cases it won't.
TCP is more sophisticated. It is a connection-oriented, reliable protocol, with sequencing mechanism, flow, and congestion control. These subjects will be discussed later in this chapter.
SCTP is a reliable, connection-oriented protocol that allows the transfer of multiple streams per connection, optional bundling of multiple user messages into a single SCTP packet, support for cookies, multi-homing, and other mechanisms. It was initially developed for carrying signaling messages in cellular networks, and later implemented with other application protocols.