Wireshark TCP sequence analysis

Wireshark has a built-in filter, tcp.analysys.flags, that will show you packets that have some kind of expert message from Wireshark; tcp.analysis.flags is shown in the TCP section of the Packet Details pane. Under that, expand SEQ/ACK analysis then expand TCP Analysis Flags. This will tell you exactly what triggered tcp.analysis.flags. A few examples include:

  • TCP Retransmission
  • TCP Fast Retransmission
  • TCP DupACK
  • TCP ZeroWindow
  • TCP ZeroWindowProbe

TCP retransmission

TCP makes the transmission of segments reliable via sequence number and acknowledgement. When TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted. During TCP retransmission, the sequence number is not changed until the retransmission timeout happens.

Open the example tcp-retransmission.pcapng in Wireshark and add a Sequence number column, as shown in the following screenshot:

TCP retransmission

As you can see in the preceding screenshot:

  • After sending tcp.seq == 1870089183 a lot of TCP retransmission occurs
  • A lot of TCP Retransmission can result in operation timeouts

For another example, open the file syn_sent_timeout_SSH.pcapng in Wireshark, and observe the TCP retransmission flow.

Tip

KeepAlive is not a retransmission.

Lab exercise

The steps to reproduce the TCP retransmission are as follows (this lab is performed in CentOs6 using the telnet and nc command utilities):

  1. Set up two machines: HOST-A (Server) and HOST-B (client).
  2. On HOST-A start the server and configure the firewall rule as shown:
    [bash ~]# iptables -A OUTPUT -p tcp --dport 8082 -j DROP
[bash ~]# iptables save
[bash ~]# nc -l 8082
  3. On the HOST-B machine open Wireshark, start capturing the packets, and choose display filter tcp.port==8082.
  4. On the HOST-B machine run the telnet command; change the IP information to your actual server location:
    [bash ~]telnet 128.136.179.233 8082
  5. Verify the TCP state on the HOST-B machine:
    bash$ netstat -an |   grep 8082
tcp4       0      0  192.168.1.101.64658    128.136.179.233.8082   SYN_SENT
  6. In Wireshark, view and analyze the captured packet using the previous step.

In order to solve operation timeouts, verify the ACL configuration; it allows the incoming packet from the source IP.

TCP ZeroWindow

Open the tcp_zero_window.pcapng file in Wireshark and add tcp.window_size_value to the column.

The TCP window size represents how much data a device can handle from its peer at one time before it is passed to the application process.

TCP ZeroWindow

As shown in the preceding screenshot:

  • Add window_size to the Wireshark column and look for the packet where tcp.window_size=0.
  • TCP headers with a window size of zero indicate that the receiver's buffers are full. This condition arrives more rapidly for writes than reads; in this condition tcp.window_size_value is set to 0 and tcp.window_size == 0.
  • The segment is exactly 1 byte.

Tip

SYN/RST/FIN flags are never set on TCP ZeroWindow.

SYN/RST/FIN flags are never set on TCP Window Full.

Troubleshoot the ZeroWindow condition:

  • Check the application has sufficient memory to start with
  • Tune the TCP parameters to obtain a larger window size; check the sysctl.conf file with these parameters:
    • net.core.rmem_max
    • net.core.wmem_max
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_wmem
  • Check the receiver is not running too many processes

TCP Window Update

Wireshark marks a packet as Window Update when the window size has changed. A Window Update is an ACK packet, and only expands the window; this is normal TCP behavior.

Open the tcp_window_update.pcap file in Wireshark and observe that a TCP Window Update event is set, as shown:

TCP Window Update

Note

A Window Update is a 0-byte segment with the same SEQ/ACK numbers as the previously seen segment and with a new window value.

TCP Dup-ACK

Duplicate ACKs are sent when there is fast retransmission. In this scenario the same segment will be seen often. Open duplicate_ack.pcapng and apply the tcp.analysis.duplicate_ack filter, as shown:

TCP Dup-ACK

As you can see in the previous screenshot:

  • Duplicate ACKs occur when the Window/SEQ/ACK is the same as the previous segment and if the segment length is 0
  • Duplicate ACKs can occur when there is a packet loss, in which case a retransmission can be seen
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.65.61