First: Packet transmission time delta (not in section)
If there is a significant delta between SYN and SYN-ACK packets, you're closer to the client
If there is an insignificant delta between SYN and SYN-ACK packets, you're closer to the server
The delay would be between the SYN-ACK and ACK
Source/Destination ports
Stream Index
Identifies the conversation stream
Helpful if multiple TCP conversations going on at once
Conversation Completeness
Tracks which handshakes the conversation has received (SYN, SYN-ACK, FIN, etc.)
A "complete" conversation has everything
Segment length
How much data is encapped in the packet
Sequence/Acknowledgement numbers
First number is the ISN (Initial Sequence Number)
Usually totally random and very large
Wireshark converts the raw ISN to be a relative ISN
e.g., 234908572139847589234 = 1
The Sequence number is the one generated by the sender
The Acknowledgement number is the sequence number the sender predicts it will receive in the host's next packet
The next bit is called a ghost bit
Subsequent numbers are based off the TCP Segment Length
Confirms receipt of all sent bytes
Flags
The first 4 flags (Reserved, Accurate ECN/Nonce, Congestion Window Reduced, ECN-Echo, and Urgent) are not often used
The last 5 flags (Acknowledgement, Push, Reset, Syn, and Fin) are frequently used
Ack: Once established, basically every packet will have an ACK flag
Push: Sending data that should should be processed quickly
It's the end of a block, should be sent out the door quickly, etc.
Reset/Fin: Used to close a conversation
Syn: Used to initiate a conversation (SYN, SYN/ACK)
Window Size
2. The amount of data that can be received at once
3. Think of it like a receive buffer
1. If the other host sends more data than the other can receive, it will cause congestion and issues
4. 2 byte value
1. Absolutely highest value is 65535 bytes
2. Not ideal for modern networks
3. TCP Options attempts to fix this
TCP Options are exchanged in the SYN packets
Maximum Segment Size (MSS): An advertised value in bytes
Not negotiated, just an advertisement
Windows scale: Allows sender the multiple the Window Size value by a certain amount
Can increase window size up to 1 gigabyte
SACK (Selective Acknowledgement): Allows acknowledgement of non-contiguous datablocks
Both sides must support
Closing TCP Connections
Two ways to shut down
Fin: A clean shutdown
Reset: An abortive release
Common during scans to send a reset to connection requests on ports you're not listening on
When scan requests hit open ports, you'll often see SYN, SYN-ACK, ACK, RST
For scans that hit closed ports, you'll often see SYN, then RST immediately from the target host
If the scan is blocked by a firewall, there won't be any response
If a packet crashes, nothing happens, sessions end unexpected, etc., it can indicate a reset
Not necessarily bad on their own, but if there are a lot of them, or people are complaining about disconnected sessions, can indicate a problem
TCP Troubleshooting
Convenient Columns to track TCP packet sequence and receipt
TCP Segment length
Relative Sequence Number
Ack number
Since the client acknowledgement doesn't include new data, its Seq number doesn't change
Dropped TCP Packets
tcp.analysis.flags are Wireshark analysis flags saying that something is missing
Big chunk of missing packets
Missing data between 1095618 and 1047438
There are 48,180 missing bytes; divide by maximum segment size (1460) to get 33 packets (32 missing packets and the last received packet)
Client sends a block of Dup ACKs, which tells the sender which packets it needs to retransmit
A Duplicate Acknowledgement number goes out to last-good packet before missing chunk
In TCP Options, under Selective ACK (SACK), the missing data
Provides the left edge (first missing packets) and right edge (first packet received after missing packets)
When looking for the retransmission, check the "Next Sequence Number" or add the TCP Length to the last good Seq number
Sometimes Wireshark tracks retransmissions as "Out-of-order"
When you see a lot of packets missing in a row, it can imply a router buffer issue
When it's spottier, it can be a link-layer issue
TCP Keep-Alive Packets
TCP will send keep-alive packets after a set period of inactivity
Keep-alive packets roll the sequence number back one, add a single byte to length, and are basically checking with its stateful partner if it still has an established connection
Example:
Client sends data to HTTP server, with a next-SEQ number of 1496.
Server responds quickly with ACK of 1496
After 45 seconds of inactivity, Client sends TCP Keep-Alive by decrementing the next-SEQ by 1 to 1495, and adds a ghost byte
Server responds quickly with ACK of 1496, indicating the connection is still alive, but service has not responded yet.