Remote Work Tools

Network issues kill remote work productivity. When your video call drops or VPN slows to a crawl, you need tools to diagnose fast without calling IT. This guide covers the essential diagnostic toolkit: from simple ping checks to traffic analysis, covering macOS, Linux, and Windows.

Table of Contents

Baseline: Know Your Normal Numbers

Run these on a good day and save the output for comparison:

# Your public IP and ISP
curl -s https://ipinfo.io | jq '{ip, org, city, region}'

# Baseline speed (use Speedtest CLI)
# macOS/Linux
brew install speedtest-cli
speedtest-cli --simple
# Download: 450 Mbps, Upload: 45 Mbps, Ping: 8ms

# Baseline DNS latency
time dig @8.8.8.8 google.com
# real 0m0.014s — under 50ms is good

# Baseline to key servers
ping -c 10 8.8.8.8
# Round trip time: avg 12ms — under 30ms for US

# Check network interface stats (macOS)
networksetup -listallhardwareports
ifconfig | grep -A4 'en0:'

# Check for packet errors or drops (Linux)
ip -s link show eth0
# Look for: errors, dropped, overruns > 0

# macOS: check WiFi signal strength
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I | grep -E 'SSID|RSSI|channel|lastTxRate'
# RSSI: -65 dBm is good; below -75 dBm is problematic

# WiFi channel utilization
airport -s  # Scan nearby networks, find congested channels

Layer 2: Connectivity

# Basic ping with statistics
ping -c 20 8.8.8.8
# Key: avg < 30ms (local), < 80ms (regional), 0% packet loss

# Ping multiple targets to isolate where loss starts
ping -c 10 192.168.1.1    # Router: should be < 2ms
ping -c 10 1.1.1.1        # ISP exit: if bad, ISP issue
ping -c 10 8.8.8.8        # Google: if good but above bad = ISP routing

# Continuous ping (Ctrl+C to stop)
ping 8.8.8.8

# macOS: network quality test (built-in since macOS 12)
networkQuality
# Upload/download/responsiveness measured

Layer 3: Traceroute

# Standard traceroute
traceroute google.com

# MTR: combines ping + traceroute, shows continuous loss per hop
# Install
brew install mtr   # macOS
sudo apt install mtr  # Ubuntu

# Run MTR (best for diagnosing routing issues)
sudo mtr --report --report-cycles=20 google.com
# Look for: hop with suddenly high Loss% = problem node
# Last hop 100% loss with no prior loss = firewall (normal)

# MTR output example:
Host                     Loss%   Snt   Avg  Best  Wrst StDev
1. 192.168.1.1             0.0%    20   1.2   0.9   2.1   0.3  ← router: fine
2. 10.20.30.1              0.0%    20   8.4   7.1  12.0   1.1  ← ISP: fine
3. 72.14.215.100           0.0%    20  10.2   9.8  11.0   0.3  ← ISP backbone: fine
4. ???                     100%    20   0.0   0.0   0.0   0.0  ← filtered, normal
5. google.com              0.0%    20  11.3  10.9  12.0   0.3  ← destination: fine

Layer 4: DNS Diagnostics

DNS failures cause apps to hang before any connection starts:

# Check DNS resolution speed
time dig google.com
time dig @1.1.1.1 google.com   # Cloudflare
time dig @8.8.8.8 google.com   # Google
time dig @9.9.9.9 google.com   # Quad9

# Check which DNS server you're actually using
cat /etc/resolv.conf   # Linux
scutil --dns | head -20  # macOS

# Test DNS over TLS/HTTPS
dig @1.1.1.1 google.com +tls  # DNS-over-TLS
curl -s "https://cloudflare-dns.com/dns-query?name=google.com&type=A" \
  -H "Accept: application/dns-json" | jq '.Answer[].data'

# Flush DNS cache
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder  # macOS
sudo systemd-resolve --flush-caches  # Linux (systemd)
ipconfig /flushdns  # Windows

# Check for DNS hijacking (compare results)
dig @8.8.8.8 checkip.dyndns.org TXT +short
dig @1.1.1.1 checkip.dyndns.org TXT +short

VPN Diagnostics

# Check if VPN is connected
ifconfig | grep -E "tun|tap|utun|wg"  # Look for tunnel interface

# Check VPN routing
ip route | grep -E "tun|wg"  # Linux
netstat -rn | grep utun  # macOS

# Verify traffic is going through VPN
curl -s https://ipinfo.io/ip  # Should show VPN exit IP

# WireGuard status
sudo wg show
# Look for: latest handshake < 3 minutes, transfer bytes increasing

# OpenVPN log
sudo journalctl -u openvpn@client -n 50  # Linux
# macOS: check Tunnelblick logs

# MTR through VPN to internal host
sudo mtr --report 10.0.0.1  # Internal IP via VPN

Bandwidth and Latency Under Load

# Install iperf3 for bandwidth testing
brew install iperf3  # macOS
sudo apt install iperf3  # Ubuntu

# If you have an iperf3 server on your network:
# Server side:
iperf3 -s

# Client side:
iperf3 -c server-ip -t 30  # 30 second test
iperf3 -c server-ip -u -b 10M  # UDP test at 10 Mbps (good for VoIP simulation)
iperf3 -c server-ip --bidir  # Bidirectional test

# Test during a video call to see real impact
iperf3 -c public-iperf3-server -p 5201
# Public test servers: iperf.he.net, bouygues.iperf.fr

Port and Firewall Checks

# Test if a port is reachable
nc -zv git.example.com 22    # SSH
nc -zv api.example.com 443   # HTTPS
nc -zv smtp.example.com 587  # SMTP

# Scan local network for a host
nmap -sn 192.168.1.0/24  # Ping scan (find devices)
nmap -p 22,80,443,5432 192.168.1.10  # Port scan specific host

# Check what's listening locally
ss -tulpn  # Linux (shows process names)
lsof -iTCP -sTCP:LISTEN  # macOS

# Test HTTP connectivity
curl -v --max-time 10 https://api.example.com/health
# Look for: TLS handshake time, TTFB, total time
curl -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | Total: %{time_total}s\n" \
  -o /dev/null -s https://api.example.com

Packet Capture

When nothing else works, capture traffic:

# macOS/Linux: tcpdump
sudo tcpdump -i en0 -n host 8.8.8.8 and port 53
sudo tcpdump -i en0 -n 'tcp port 443' -w /tmp/capture.pcap

# Analyze with Wireshark
brew install --cask wireshark

# Quick analysis: count by destination
sudo tcpdump -i en0 -n -c 1000 | awk '{print $5}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

# Monitor bandwidth by process (macOS)
brew install nettop
sudo nettop -d  # Shows bytes in/out per process

Quick Diagnostic Checklist Script

#!/bin/bash
# scripts/network-check.sh
echo "=== Remote Work Network Diagnostics ==="
echo "Date: $(date)"
echo ""

echo "--- External IP ---"
curl -s --max-time 5 https://ipinfo.io | jq -r '"IP: \(.ip) | ISP: \(.org)"'

echo ""
echo "--- Router Ping ---"
ROUTER=$(netstat -rn | grep 'default' | awk '{print $2}' | head -1)
ping -c 5 -q "$ROUTER" 2>&1 | tail -3

echo ""
echo "--- Google DNS ---"
ping -c 5 -q 8.8.8.8 2>&1 | tail -3

echo ""
echo "--- DNS Resolution ---"
time_ns=$(date +%s%N)
dig @8.8.8.8 google.com > /dev/null 2>&1
echo "DNS latency: $(( ($(date +%s%N) - time_ns) / 1000000 ))ms"

echo ""
echo "--- Speed Test ---"
speedtest-cli --simple 2>/dev/null || echo "speedtest-cli not installed"

echo ""
echo "=== Done ==="

chmod +x scripts/network-check.sh
./scripts/network-check.sh

Diagnosing Video Call Degradation Specifically

Packet loss under 1% is imperceptible on HTTP. For video calls, even 0.5% sustained packet loss causes visible artifacts. Jitter — variation in packet arrival timing — is often more disruptive than raw latency.

Measure Jitter and Packet Loss to Call Servers

# Test against Zoom's media servers
# Replace with your actual call platform's server range
sudo mtr --report --report-cycles=60 --interval=0.5 \
  zoom.us

# For Google Meet, test against the STUN servers
ping -c 100 -i 0.2 stun.l.google.com
# stddev > 10ms = jitter problem; any loss = call quality issue

# Simulate VoIP packet profile with iperf3
# Server side:
iperf3 -s

# Client side: 100kbps UDP (typical audio codec bandwidth)
iperf3 -c server-ip -u -b 100k -l 160 -t 60
# Look for: jitter > 20ms or packet loss > 0.5% = call will degrade

WiFi vs Ethernet Quick Test

If you suspect your WiFi is the issue, run this comparison:

# Run while on WiFi
ping -c 50 -i 0.2 8.8.8.8 | tail -3
# Note stddev

# Plug in ethernet, disable WiFi
networksetup -setairportpower en0 off   # macOS
# or
nmcli radio wifi off                    # Linux

ping -c 50 -i 0.2 8.8.8.8 | tail -3
# Compare stddev — ethernet should be 0.1-0.5ms vs WiFi's 1-10ms

A stddev difference of more than 5ms between WiFi and ethernet points to RF interference or a congested wireless channel rather than ISP issues.

Reading ISP Problem Patterns

Different failure modes produce different diagnostic signatures. Use this as a reference:

SYMPTOM                         LIKELY CAUSE              CONFIRM WITH
-------------------------------------------------------------------
High ping to router (>5ms)      Bad cable / WiFi issue    Ethernet test
High ping past router           ISP congestion            MTR to 8.8.8.8
DNS slow, ping fine             DNS server issue          compare dig times
All traffic slow, VPN fine      ISP shaping               compare VPN vs direct
VPN connects, drops every 5min  UDP timeout               switch VPN protocol
Morning fine, afternoon slow    Neighborhood congestion   run at different times
Upload degraded, download fine  DOCSIS upstream issue     iperf3 bidir test

Logging Network Events Over Time

For intermittent issues, run a background logger to correlate dropouts with time of day:

#!/bin/bash
# scripts/network-logger.sh
# Run in background: nohup ./network-logger.sh &

LOG="network-events-$(date +%Y%m%d).log"

while true; do
  TS=$(date '+%Y-%m-%d %H:%M:%S')
  LOSS=$(ping -c 10 -q 8.8.8.8 2>&1 | grep -oE '[0-9]+% packet loss' | cut -d% -f1)
  LATENCY=$(ping -c 10 -q 8.8.8.8 2>&1 | grep 'avg' | awk -F'/' '{print $5}')

  if [ "$LOSS" != "0" ] || (( $(echo "$LATENCY > 100" | bc -l) )); then
    echo "$TS | ALERT | loss=${LOSS}% | avg_rtt=${LATENCY}ms" | tee -a "$LOG"
  else
    echo "$TS | OK | loss=${LOSS}% | avg_rtt=${LATENCY}ms" >> "$LOG"
  fi

  sleep 60
done

Run this during your work day for a week, then share the log with your ISP when requesting escalation. Concrete timestamps and loss percentages get faster resolution than “the internet is slow sometimes.”

Explore Our Developer Guides

© 2026 theluckystrike Developer Guides