roro9stack/site/content/howto/network-check.md

+++ 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 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). "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).

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.

7. tls <host>: a secure connection fails ("TLS error")? This shows the certificate and the verdict:

   tls: git.twis.la:443 answered in 709 ms
   tls: for git.twis.la, by YE2
   tls: valid 2026-09-15 to 2026-12-14, 67 days left
   tls: this device trusts it
   

   "NOT trusted here" comes with the reason: expired, not for that name, or not signed by a root this device has. The last is normal for a Gemini capsule, which signs its own certificate, and a problem for an update server. It needs about 70 KB of free memory: close IRC first if it says so.

8. ntp: is the clock right? A clock that is wrong by more than a few minutes breaks secure connections and the VPN.

   ntp: pool.ntp.org (195.72.61.39), stratum 2, 50 ms away
   ntp: this clock is right, to 0.1 s
   

What is the device itself offering?

netstat lists what it listens on, and who is connected:

netstat: tcp 3232 listens (updates)
netstat: tcp 2323 listens (Debug Console)
netstat: tcp 172.16.42.25:2323 - 172.16.42.249:51858

The update port is always there (updates are signed). The Debug Console and sharing appear only while you have them on.

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.