When higher-level tools disagree with reality, capture the actual packets. tcpdump and Wireshark show exactly what’s on the wire — the ultimate source of truth.
Why: every other tool infers what is happening, but a packet capture shows the actual bytes on the wire — so when logs and reality disagree, you capture. When: reach for it for the hard problems: is the SYN even arriving? is the server resetting the connection? is there retransmission? Where: capture as close to the problem as possible and filter tightly, or you drown in traffic.
# Capture on an interface, filtered to one host and port:
sudo tcpdump -i eth0 host 192.168.1.20 and port 443
# Common filters:
sudo tcpdump -i any icmp # just pings
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' # connection attempts
sudo tcpdump -i eth0 -w capture.pcap # save to open later in WiresharkWhy: most "connection" problems are visible in the three-way handshake — a SYN with no SYN-ACK means the server never answered (firewall or down), a RST means it actively refused — and you can see this directly in a capture. When: use it to prove which side is failing. Where: retransmitted SYNs (the client trying again) with no reply confirm the traffic is being dropped inbound.
Healthy TCP connection (three-way handshake):
client -> server SYN
server -> client SYN, ACK
client -> server ACK -> connected
Failure signatures in a capture:
SYN, then nothing server never replied (firewall/down)
SYN -> RST server actively refused (port closed)
SYN, SYN, SYN (retries) traffic dropped inbound
many retransmissions loss / congestion on the pathWhy: "the network is slow" needs a number — iperf generates traffic between two hosts and measures actual throughput, separating a real bandwidth problem from a perception or an application issue. When: use iperf between endpoints you control; a speedtest for internet-facing checks. Where: compare measured throughput against the link’s rated capacity to confirm or clear the network.
# On the server:
iperf3 -s
# On the client — measure throughput to the server:
iperf3 -c 192.168.1.50
# Internet-facing quick check:
speedtest-cli # or the speedtest.net app
# Measured far below the link's rated speed -> real bottleneck.
# At/near rated speed -> the network is fine; look at the application.