When a Kapadokya Guesthouse Router Lied About Its Uptime

A small guesthouse in Ortahisar runs two things I care about: a booking page and a Wi-Fi network that guests judge within the first ten minutes. Last spring the owner reported that the Wi-Fi “disappears for a few minutes every evening.” The router’s admin page showed 47 days of uptime. That number was the first thing that misled me.

The setup was modest: an Asus router on the ground floor, one TP-Link extender on the terrace, a 16-port switch in a closet, and about 30 devices at peak. The router’s log buffer held maybe 200 lines, so by the time anyone noticed the outage, the evidence had rolled off. I needed a record that outlived the buffer and did not depend on the router telling the truth.

I put a Raspberry Pi on the guest VLAN and polled three things every 60 seconds: the router’s LAN IP, the ISP gateway, and a DNS server. The goal was to separate “Wi-Fi died” from “ISP died” from “the router rebooted.” The script writes one CSV line per check, with a timestamp from the Pi itself, so a router clock reset cannot corrupt the sequence.

#!/bin/sh
# /usr/local/bin/netcheck.sh — run from cron every minute
TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)
GW=192.168.1.1
ISP=$(ip route | awk '/default/ {print $3; exit}')
R=timeout 3 ping -c1 -W2 "$GW" >/dev/null 2>&1 && echo up || echo down
I=timeout 3 ping -c1 -W2 "$ISP" >/dev/null 2>&1 && echo up || echo down
D=timeout 3 ping -c1 -W2 1.1.1.1 >/dev/null 2>&1 && echo up || echo down
echo "$TS,$R,$I,$D" >> /var/log/netcheck.csv

Cron line:

* * * * * /usr/local/bin/netcheck.sh

A week of that CSV showed the pattern plainly. Between 20:40 and 20:55, the router answered while the ISP gateway did not. The router had not rebooted; the uplink had dropped. The extender was innocent. The admin page’s uptime counter was technically true and practically useless, because it counted the router’s own process, not the path to the internet.

The mechanism matters more than the script. A device can be up and still be unreachable from where it matters. Polling the gateway and the ISP separately turns a vague “Wi-Fi is bad” into a layer-specific claim. The cost is small: three pings a minute, a few megabytes of CSV a month, and one more always-on box that itself needs a UPS if you want it to survive the same outage it is measuring. I did not add a UPS at first, and the Pi dropped during one evening cut, leaving a gap exactly where the interesting data should have been.

Where this breaks: if the ISP blocks ICMP, the ISP column reads “down” while the connection is fine, so use a TCP check against a known host as a cross-check. If the Pi is on Wi-Fi instead of Ethernet, its own link flaps look like network outages. And a 60-second interval will miss short drops that guests still notice; 15 seconds is better if the router tolerates it. I also learned not to trust the router’s log timestamps after a power cut, which is why the Pi stamps every row.

What I still cannot explain is why the uplink dropped at nearly the same evening hour for six days and then stopped. The ISP’s support line gave me nothing usable. If you have run a small guesthouse or cafe network in Turkey and seen a similar evening pattern, what did it turn out to be: line noise, PPPoE renegotiation, or something on the provider’s side?