Version 5 Manual

TCP Packets


PingPlotter's TCP packet type sends real TCP SYN probes to a specific port on the destination. This is the same kind of handshake your browser performs when opening a web page. Use TCP when the network or destination drops ICMP and UDP (common on corporate networks, cloud edges, and load-balanced destinations), or when you want a trace that mirrors what your actual TCP-based application sees.

Enabling TCP on Windows

Go to Edit → Options → Engine and set Packet Type to TCP. PingPlotter will prompt you to install the TCP Helper Service. Click Install TCP Helper Now to proceed. The helper is a lightweight Windows service that generates the TCP probes. Once installed, it runs on demand and idles out when no traces are active.

Windows Server

The TCP Helper Service is not available on Windows Server editions because the helper's kernel-mode WFP driver requires Microsoft driver attestation signing, which has different requirements on Server SKUs. If you need TCP traceroute on Windows Server, you can use the legacy PCap-based TCP engine instead. See Raw TCP sockets and Npcap for setup instructions.

Enabling TCP on Mac

Go to PingPlotter → Settings → Engine and set Packet Type to TCP. PingPlotter will prompt you to install a helper driver if the service has not been installed.

Picking a port

Port 443 (HTTPS) is the right choice in almost every case. Nearly every firewall, captive portal, and middlebox lets it through because blocking it would break the web.

The main reason to choose a different port is when you're diagnosing a specific service. Use the port that service actually listens on (22 for SSH, 25 or 587 for mail, 3306 for MySQL, etc.) so the trace follows the same path your real connection takes, including any middlebox rules specific to that port.

What to expect

TCP traceroute solves real problems, but it behaves differently from ICMP in a few ways:

  • Sparser hop data. Some routers rate-limit or skip Time Exceeded messages for TCP. Hops that appear cleanly on an ICMP trace may show as timeouts on a TCP trace, even though traffic is passing through them.
  • Possible route inaccuracies at NAT borders. TCP traceroute is less common than ICMP, so some routers and NAT devices handle it less accurately. You may see hops at the wrong position or IPs that don't match other tools. Compare against an ICMP trace to the same destination to spot differences.
  • Different path than ICMP. Load balancers and ECMP routers hash on the protocol number and ports to pick a next hop. Because TCP and ICMP differ, they can take different routes. This is actually useful when diagnosing TCP-specific issues.
  • Destination may filter your chosen port. An open port returns SYN+ACK. A closed port returns RST. Both count as reachable. A filtered port returns nothing, which looks the same as the destination being down. If your trace reaches every hop except the destination, try a different port.
  • Occasional latency spikes at the destination. When the destination accepts a SYN, it replies with SYN+ACK and waits for an ACK to complete the handshake. If that SYN+ACK is lost on the return path, the destination retransmits it after a timeout (typically around 1 second on Linux, 3 seconds on Windows). PingPlotter records the retransmit as the first response, so you may see inflated readings at roughly those intervals. Lowering the trace timeout below the destination's retransmit interval will cause late retransmits to show as timeouts instead of inflated latency.
  • Fixed packet size. TCP probes are 40 bytes (IPv4) or 60 bytes (IPv6). The Cargo / packet size setting does not apply, so TCP can't be used for MTU testing.

Advantages over the legacy PCap-based TCP engine (Windows)

PingPlotter has offered TCP traceroute on Windows for years using a legacy engine based on Npcap. The new TCP packet type introduces a purpose-built option that addresses several limitations of that approach:

  • No Npcap install required. The helper ships inside the PingPlotter installer, so no separate third-party download is needed.
  • Works over VPNs, tunnels, and non-Ethernet links. The new engine operates at the IP layer through the OS network stack, so VPN adapters, WireGuard tunnels, and PPP links work the same as wired Ethernet.
  • Survives network changes. Wi-Fi roams, VPN connect/disconnect, and tether handoffs trigger automatic re-resolution. No restart needed.
  • Correct NIC selection on multi-homed machines. Uses the same routing logic the OS uses for real outbound traffic.
  • Full IPv6 support. IPv4 and IPv6 go through the same engine and parsing code.
  • Microsoft-attested driver. Signed through Microsoft's driver attestation program, so Windows trusts it without third-party driver prompts.

On Mac, TCP traceroute is entirely new. There is no legacy engine to compare against, but the Mac implementation shares most of the same benefits listed above (VPN support, network change handling, correct NIC selection, and full IPv6 support).

The legacy engine on Windows is still available if you need it, such as on a locked-down machine where you can't install a service.

Troubleshooting

If you see unexpected routes (especially hops at the wrong position), open the engine settings for the TCP packet type and look at the Troubleshooting section. The Detailed logging options let you enable verbose output for specific categories (packet capture, route resolution, IPC, etc.) for a bounded time window. The log file is attached automatically when you submit a support ticket.

You rarely need to turn this on yourself. If you're hitting a problem, submit a ticket and we'll tell you which categories to enable.