roro9stack/site/content/howto/network-check.md at 9b6457d1ec0b7aabaedbf41d90d7b809e5bfaa60

twisla/roro9stack

Public Access

Fork 0

Files

T

twislaandClaude Opus 5.5 ed7abdcaf5

CI / build (pull_request) Successful in 1m38s

Details

Site / build (pull_request) Successful in 11s

Details

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

2.5 KiB

Raw Blame History

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

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

2.5 KiB Raw Blame History

With the VPN up

Good to know

2.5 KiB

Raw Blame History