top of page
  • Writer's pictureLaura Chappell

How to Improve Wireshark's "TCP Errors" Graph Line

The "Bad TCP" designation is seen in the coloring rules, while the "TCP Errors" designation is seen in the IO Graph. Are they the same? No. Should they be? Maybe.

Over time, Wireshark has defined the "Bad TCP" coloring rule in different ways.

Originally, Bad TCP was defined as just any packets that match the tcp.analysis.flags filter. That included TCP lost packets, retransmissions, fast retransmissions, spurious retransmissions, and duplicate ACKs. All of those items are indications of network problems. So far, so good.

The Bad TCP Coloring Rule

Over time, however, the Bad TCP coloring rule changed to exclude TCP keepalives, TCP Keepalive ACKs, and Window Updates. That was a great change since those TCP packet types do not typically indicate a problem exists on the network.

Wireshark coloring rules window

TCP keepalives are used to retain a TCP connection when no data is traveling between TCP peers. This prevents you from having to reestablish a connection when you return to the application. TCP keepalive ACKs are the response to TCP keepalives.

TCP Window Updates are good - they are a sign that there is more TCP receive buffer space available at the sender.

The TCP Error IO Graph Line

It seems to me that the TCP Error graph line (bar, actually) should match the Bad TCP coloring rule. It doesn't. TCP Errors uses a display filter for the tcp.analysis.flags items including keepalives and window updates.

Wireshark IO Graph

A Quick Change

Do you want to exclude keepalives and window updates from your TCP Errors graphing? Simply cut and paste the Bad TCP coloring rule filter into your IO Graph TCP Errors Display Filters column.

Edited IO Graph



bottom of page