Wireshark notes - 3 - Application Errors and Advanced IO Graph

dns.flags.rcode > 0
http.response.code >= 400 or
http.response.code > 399

HTTP response code
1xx: Informational—Request received, continuing process
2xx: Success—The action was successfully received, understood, and accepted
3xx: Redirection—Further action must be taken in order to complete the request
4xx: Client Error—The request contains bad syntax or cannot be fulfilled
5xx: Server Error—The server failed to fulfill an apparently valid request


SMB response code(NT status) of 0 indicates the request was successful.
smb.nt_status > 0 || smb2.nt_status > 0


SIP is a request/response-based application. SIP can run over UDP or TCP. When SIP is configured to run over TCP, we hope to see an ACK to our SIP request in a reasonable amount of time and then a successful response. SIP response codes are
1xx: Provisional — request received, continuing to process the request.
2xx: Success — the action was successfully received, understood, and accepted.
3xx: Redirection — further action needs to be taken in order to complete the request.
4xx: Client Error — the request contains bad syntax or cannot be fulfilled at this server.
5xx: Server Error — the server failed to fulfill an apparently valid request.
6xx: Global Failure — the request cannot be fulfilled at any server.

sip.Status-Code >= 400 or
sip.Status-Code > 399

----------------------------------------------------------------------------------------------------

A picture is worth a thousand packets

Use an IO Graph to compare the throughput of separate conversations

Use an IO Graph to compare application throughput based on port numbers in use Consider using Advanced IO Graphs when you need the Calc functions (such as MIN, AVG, MAX)

When the application runs over TCP and you have the option of using an application name filter (such as http), it is recommend you use a port-based filter (such as tcp.port==80) instead in order to include the TCP overhead (such as TCP handshake packets, ACKs, FINs, and RSTs) in your graph.

The Advanced IO Graph offers Calc functions for summing the contents of a field, counting the occurrences of a field and more.
  -Use Calc: SUM(*) to add the contents of a numerical field, such as tcp.len, which does not exist in a packet, but is Wireshark's field to count just data bytes in packets.
  -Use Calc: COUNT FRAMES(*) to count the occurrence of specific type of frame or Expert Infos item such as tcp.analysis.retransmission.
  -Use Calc: COUNT FIELDS(*) to count the occurrence of a field, such as the IP ID (ip.id) field which occurs twice in some ICMP packets.
  -Use Calc: MIN(*), AVG(*) and MAX(*) to graph the minimum, average and maximum value of a numerical field, such as the tcp.window_size field.
  -Use Calc: LOAD(*) to graph response time fields, such as smb.time.

There is no field in a packet called tcp.len, but Wireshark uses this value to define the number of data bytes in each TCP segment. Tcp.len value does not count header values.

---------------------------------------------------

Detect Consistently low throughput due to low packet sizes

Low packet sizes may be caused by an application that intentionally wants to transfer smaller amounts of data. Low packet sizes can also be an indication of a low Maximum Segment Size (MSS) setting. For MSS setting, check tcp handshake.

Identify Queuing Delays along a Path

Interconnecting devices can inject delays by queuing (holding the packets temporarily before forwarding them) along a path. Consider using a traffic generator to detect queuing along a path. A tool such as iPerf/jPerf can be used to transmit traffic at a steady rate.

Correlate drops in Throughput with TCP Problems (the Golden Graph)

This graph can determine if throughput issues are related to network problems such as lost packets or

zero window sizes. This is a great graph to build whenever anyone complains about slow performance of a TCP-based application.

Graph Time Delays

This is a great way to identify slow responses for an application that does not have a delta time function.

Graph High TCP Delta Time (TCP-Based Application)

Some TCP-based applications (such as HTTP and SMB) have a delta time tracking function in Wireshark. If the application does not have the delta time tracking function built into the dissector, you can still graph high delta times using tcp.time_delta.

Graph Other Network Problems

You can graph window size issues based on the TCP analysis flag (tcp.analysis.zero_window) or the actual Calculated window size file value.

You can graph packet loss and recovery processes using the TCP analysis flags for each part of the process. 

Although TCP time-sequence graph can be very busy, it can depict not only packet loss but it can also depict selective ACKs.

The above graph clearly depicts the points in the trace where Wireshark noticed packet loss. In addition, the graph depicts the packet loss recovery process by graphing Duplicate ACKs and Retransmissions.