Shell: ping, nslookup, port, traceroute, ifconfig and arp (#90)

Network troubleshooting from the device itself, in the Shell and over both consoles. ping, nslookup, port and traceroute each run on a task of their own and print as they go, to the console that asked; one at a time, and `cancel` stops it. ifconfig and arp answer at once: the interfaces (Wi-Fi and the VPN), which is the default route, the DNS servers, the neighbours. nslookup asks a DNS server itself, so it can say which server answered and in how long, and ask another. A sized ping finds what a tunnel really carries. With a how-to, "When the network doesn't work", and the rest of the docs. tls, ntp and netstat from the issue's list are not in this. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
2026-10-08 02:29:04 +02:00
parent 86172c0342
commit ed7abdcaf5
16 changed files with 969 additions and 6 deletions
@@ -0,0 +1,54 @@
+++
+title = "When the network doesn't work"
+description = "Find out where it stops, from the device itself: the Wi-Fi, the gateway, the names, the port, the route, the tunnel."
+weight = 12
+[extra]
+tag = "Network"
+++
+
+Open the [Shell](/guide/shell/) and go down this list. Each step says what a good answer looks like; the first bad one is where the trouble is.
+
+1. **`ifconfig`**: is there an address, and where does traffic go?
+
+   ```
+   ifconfig: vpn 10.9.0.2/32 mtu 1420, up, default route
+   ifconfig: wifi 172.16.42.25/21 gw 172.16.42.1 mtu 1500, up
+   ifconfig: dns 10.9.0.1
+   ```
+
+   No `wifi` line, or `down`: it is the Wi-Fi itself ([Settings](/guide/settings/#wi-fi)). "default route" says which way everything leaves: on `vpn`, everything goes through the tunnel.
+
+2. **`ping` the gateway** (the `gw` address): is the local network there?
+
+   ```
+   ping: 4/4 back, 0% lost, 3/3/4 ms
+   ```
+
+   Nothing back: `arp` shows whether the gateway was ever heard.
+
+3. **`ping 9.9.9.9`**: is the internet there, without names? If the gateway answers and this doesn't, the trouble is beyond your network, or in the tunnel.
+
+4. **`nslookup roro9stack.net`**: do names resolve?
+
+   ```
+   nslookup: 10.9.0.1 answered in 6 ms
+   nslookup: 65.21.233.110
+   ```
+
+   "no answer from": that DNS server is unreachable. Try another to compare: `nslookup roro9stack.net 9.9.9.9`. If that one answers, change the servers ([DNS and NTP](/guide/settings/#dns-and-ntp)).
+
+5. **`port <host> <port>`**: is the service there? `open` is good. `refused` means the machine is up and nothing listens on that port. "no answer" means it is down, or a firewall drops it.
+
+6. **`traceroute <host>`**: where does it stop? The last router that answers is the last one that works.
+
+## With the VPN up
+
+- `ifconfig` shows the `vpn` line, and "default route" on it if everything goes through.
+- `ping` the server's tunnel address first: that is the tunnel itself.
+- **Finding the tunnel's real packet size:** `ping 9.9.9.9 2 1392` (1392 bytes, plus 28 of headers, is 1420: WireGuard's usual). If that comes back and 1393 doesn't, the tunnel carries 1420. If 1392 doesn't come back either, try smaller: something on the way allows less, and the server's configuration wants a lower `MTU`.
+
+## Good to know
+
+- `cancel` stops a `ping` or a `traceroute`.
+- Some hosts and routers don't answer pings or traceroutes at all; a silent hop (`*`) in the middle of a route that goes on is normal.
+- The same commands work over the [Debug Console](/dev/debug/).