Field Tech Toolkit

Your phone can connect to the internet two different ways: through your home Wi-Fi, or through your cellular carrier (AT&T, Verizon, T-Mobile, etc.). These are completely separate networks. If we run a diagnostic test while you’re on cellular, we’re testing your carrier’s network, not your home connection — and we’d be diagnosing the wrong thing entirely.

Wi-Fi adds an extra layer between you and your router — it can be affected by distance, walls, interference from other devices, and signal congestion. Ethernet is a direct physical connection and eliminates all of those variables. For troubleshooting, Ethernet gives us the most reliable test results.

Your service type determines what’s possible. If you’re trying to host a game server, run a security camera remotely, or access your home network from outside — you generally need a static IP and the ability to port forward. Business-class connections include this by default. Residential connections often don’t, and some providers use CGNAT (Carrier-Grade NAT) which makes port forwarding impossible regardless of your router settings.

If both your modem and router are broadcasting Wi-Fi, they might be fighting each other — causing slow speeds, dropped connections, or devices jumping between networks. Knowing which network you’re on tells us which part of the chain we’re testing. It’s generally not best practice to have both broadcasting simultaneously, but during troubleshooting, having both available can help us isolate where the problem is.

Port forwarding lets traffic from the internet reach a specific device on your local network. Think of it like having a building with one public address (your IP) and many offices (your devices). Port forwarding is the directory that tells visitors which office to go to. Without it, or without a public IP, visitors can’t get in at all. CGNAT means your ISP puts you behind their router, so your “public IP” is actually shared with other customers — making port forwarding impossible from your end. RFC 6598 defines the CGNAT shared address space (100.64.0.0/10). RFC 5780 covers NAT behavior requirements.

Your home network is a chain: Device → Wi-Fi/Ethernet → Router → Modem → ISP → Internet. If something is broken, you need to know which link is failing. By connecting directly to the modem, you skip your router entirely. If the internet works when connected to the modem but not through your router, the problem is your router. If it doesn’t work even connected to the modem, the problem is upstream — your ISP or modem itself.

NAT (Network Address Translation) lets multiple devices share one public IP address. It works by rewriting the source address on outgoing packets and tracking which responses go back to which device. One layer of NAT is normal and expected. But when you stack two NAT layers, the inner router has no way to receive inbound connections from the internet — those connections hit the outer NAT first, and it has no idea where to send them. The result: anything that requires someone on the internet to connect to you fails silently. RFC 3022 defines traditional NAT. RFC 6598 defines the CGNAT shared address space (100.64.0.0/10). The private address ranges are defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Port checking from inside your own network can lie to you — your router might say a port is open even when it’s blocked by your ISP or a firewall you don’t control. Our probe server sits on the public internet and tries to connect to your port from outside, giving you the real answer. This is the “You See / The Internet Sees” perspective that matters for game servers, remote access, and any service you want reachable from outside your home. We use an external probe server (Observe Probe VPS) for this test. The connection attempt originates from our infrastructure, not your device.

DNS (Domain Name System) is like the phone book of the internet. When you type “google.com,” your computer asks a DNS server to translate that name into an IP address (like 142.250.80.14) so it can actually connect. If DNS is broken, your internet connection might be perfectly fine, but your computer can’t find anything because it doesn’t know where to go. This is one of the most common “internet is down” situations that’s actually fixable in seconds. DNS is defined in RFC 1034 and RFC 1035. The public resolvers at 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare) are free and generally faster and more reliable than ISP-provided DNS.

When a network goes down, you lose the ability to remotely access it — which creates a catch-22 for remote support. The dual-network technique solves this by separating internet access (phone hotspot) from local network access (Ethernet). Your operating system’s routing table handles this naturally: traffic to the local subnet (e.g., 192.168.x.x, 10.x.x.x) goes through Ethernet, while everything else routes through the hotspot’s default gateway. This is the same principle behind multi-homed servers and policy-based routing used in enterprise environments.

These commands talk directly to your operating system’s network stack — no browser or third-party service needed. ping tests raw connectivity (RFC 792 — ICMP Echo). traceroute maps the hop-by-hop path your packets take, showing exactly where delays or drops occur. netstat reveals what programs on your computer are actively communicating over the network. These are the same tools network engineers use every day.

No single tool does everything. Speedtest measures throughput. PingPlotter maps the path. Wireshark shows the packets. Downdetector checks if it’s just you or everyone. Together, they cover the full diagnostic spectrum from “is it plugged in?” to “which router in my ISP’s backbone is dropping 12% of my packets between hops 4 and 5.” We built the Field Tech Toolkit to handle the guided troubleshooting flow and the tests you can run right here — but for deep dives, these tools are what the pros use.