Learning Journal: Wireshark notes

some checksum algorithms are able to recover the error simply by calculating what the error is and just repari it. Some can't and so, retransmit if the protocol supports.

Flow Graph --> Statistics - Flow Graph
-TCP handshake in full view - review the handshake and patterns associated with communications
-Helps to find errors in communications

TCP Stream Graph --> Statistics - TCP Steam Graph

Service Response Time --> Statistics -
For protocls SMB, LDAP, others.

Analyzing Packet Lengths
-shows fragmentation problems
-tiny packets problems

IO Graph (covered in foundation videos)
===================================

If the application is TCP-based, you should use a display filter based on the port number in order to view the TCP overhead (such as the TCP handshake, ACKs and connection tear down) as well as the application traffic. For example, the filter tcp.port==21 would display the FTP command channel traffic, including the TCP handshake, ACKs, and the TCP connection teardown packets.

Sample useful display filters

eth.addr == d4:85:64:a7:bf:a3
ip.addr==10.1.1.1
http.request.method --to view all HTTP client request packets
dns.flags.rcode > 0 -- to identify DNS error responses
tcp.window_size < 1000 -- to identify advertised buffer space issue. Look for window update messages

Use !/not with ==/eq when you filter on a field name that matches two fields such as ip.addr, tcp.port or udp.port.
Use (!=) when you filter on a field name that only matches one field such as dns.flags.rocde or tcp.dstport

tcp.flags.syn == 1

Change the TCP Dissector Reassembly Setting to Properly Measure HTTP Response Times

Use Statistics --> Conversations to find top talkers.
Use Statistics --> IO Graph to quickly spot a throughput problem.

=======================================================
Wireshark profiles are saved in Personal configuration folder.

Normal or acceptable delays should be ignored in the trace file. They are
-Delays before DNS queries,
-delays before TCP FIN or Reset packets,
-delays before a client sends a request to server,
-delays before keep-alive or zero window probes(zero window probe is sent during a zero window situation to determine if more buffer space is avail at the target),
-delays before TLS encrypted alert followed by a TCP FIN or RST
-delays before a periodic set of packets in a connection that is otherwise idle (applicaiton's own keep alive packet)
-

Knowing what "normal" delay times are will help. These delays below do matter
-delays before a server responds with a SYN/ACK
-delays before a client completes the 3-way TCP handshake
-delays before a server sends a response
-delays before the next packet in a data stream (buffer space)
-delays before an ACK from a TCP peer (delays before transmitted data is ACKed)
-delays before a window update (tcp.window.size; no expert info warning for this "low window size" problem.

Various time measurements and application response time measurements
Delta time (frame.time_delta)
Delta displayed time (frame.time_delta_displayed and Delta time displayed)
TCP delta time (tcp.time_delta)
DNS response time (dns.time)
HTTP response time (http.time)
SMB response time (smb.time)

Using IO Graph to display latency

Calculating conversation timestamps of TCP

Wireshark numbers each separate TCP conversation with a TCP Stream index (tcp.stream) value starting with 0. After you have enabled the Calculate conversation timestamp preference setting, Time since previous frame in this TCP stream (tcp.time_delta) will be visible at the end of the TCP header. Unlike the basic delta time value, this time value tracks the time from the end of one packet in a TCP conversation (aka "stream") to the end of the next packet in that same TCP conversation.

The TCP Delta column is a key column to add when troubleshooting TCP-based applications. It's one of the first steps I use when locating the cause of poor performance of a TCP-based applications on a network.

In large trace file, to find the most active TCP conversation, use Conversations menu. From there, click on TCP/UDP and sort by Bytes. Right click on the converation with highest bytes and apply as filter.

Obtain Round Trip Time (RTT) using TCP Handshake
If capturing at the clinet, look at the tcp.time_delta value between client's TCP SYN packet and server's TCP SYN/ACK response. If at server, look at value between server's TCP SYN/ACK and clinet TCP ACK response. If capturing inside the infrastructure, add up the delta time between TCP SYN and ACK packets of the handshake.

To filter the first 2 packets of TCP handshake - tcp.flags.syn==1
To filter SYN/ACK - (tcp.flags.syn==1 && tcp.flags.ack==1)
To filter ACK, - (tcp.seq==1 && tcp.ack==1)
To filter SYN/ACK and ACK - (tcp.flags.syn==1 && tcp.flags.ack==1) || (tcp.seq==1 && tcp.ack==1) && tcp.len==0 && tcp.flags.fin==0