The Night Bus Wi-Fi Died at 2 AM Near Aksaray

The 01:30 Istanbul–Göreme night bus, a Mercedes Tourismo, was advertising a Wi-Fi network with no password. My phone connected, got a DHCP lease, and then nothing: no DNS, no gateway, five bars of lie. This was in March, on the stretch after Aksaray where the road runs straight and the driver is the only thing awake. I had a booking confirmation I wanted to re-read and a friend expecting a message when we hit Nevşehir, so I spent about forty minutes poking at it with the tools already on my phone instead of sleeping.

What I did, step by step, on a rooted Android with a terminal:

ip addr show wlan0
ip route
cat /etc/resolv.conf 2>/dev/null || getprop | grep -i dns
ping -c 3 1.1.1.1
ping -c 3 $(ip route | awk '/default/ {print $3}')

The lease said 192.168.8.x/24, gateway 192.168.8.1. ICMP to the gateway answered in 3–8 ms, so the local link was fine. ICMP to 1.1.1.1 timed out. DNS was handed out as 192.168.8.1, which is the classic captive-portal-shaped setup: the router answers DNS for everything and redirects to a login page. But curl -v http://192.168.8.1/ returned a 302 to http://portal.invalid/, and that host did not resolve. The box was trying to send me to a portal that did not exist on this network, probably because the SIM in the router had run out of data or the uplink had dropped and the router had no fallback page.

A few things I tried, in the order that made sense:

# does the router leak anything useful?
curl -s http://192.168.8.1/ | head -40
nmap -p 80,443,8080,53 192.168.8.1

# force a public resolver and see if plain DNS egress works
dig @1.1.1.1 example.com +short

# try a TCP handshake outbound
nc -vz -w 3 1.1.1.1 443

Port 53 was open on the router and answered, but only with the redirect behavior. Outbound TCP 443 failed. So the uplink was genuinely down, not just DNS-broken. Nothing to fix from my seat; the right answer was to stop poking and use the offline copy of the booking I already had in my mail app’s cache.

Why I bother doing this at all: a bus Wi-Fi that hands out leases but has no uplink is worse than no Wi-Fi, because your phone will keep the association and try to route background sync through it, draining battery and missing the 4G it could otherwise use. The practical move is to disable auto-join for that SSID and switch back to mobile data, which is what I did after confirming the uplink was dead. The cost is a couple of minutes and some battery spent on the diagnosis; the benefit is not spending the next four hours wondering why messages are not arriving.

Where this reasoning breaks: I assumed portal.invalid was a misconfiguration, but it could equally have been a deliberate block to stop people streaming video on a shared uplink. I never saw the router’s admin page, so I cannot say. On a previous trip the same symptom turned out to be a MAC allowlist that had filled up, and the fix was simply toggling airplane mode to get a new lease slot. And if you are not rooted, ip route and dig may not be there; a plain ping to the gateway and to 1.1.1.1 gets you most of the diagnosis.

What I would like to know: when you hit a captive portal that redirects to a host that does not resolve, do you treat it as a broken uplink and move on, or do you keep probing the router for a working portal path? I have gone back and forth, and I am not sure the extra ten minutes has ever paid off for me.