We've recently noticed an issue when the captive portal consistently fails to show up on iOS devices (even after hitting forget this network in network settings). There was no clear pattern (iOS version, network settings etc...).
So I went looking —I turned on verbose logging in nodogsplash, and the iOS devices appear to try and hit these two urls to check if they need to show a captive portal:
The captive portal consistently fails to display when the device tries netcts.cdn-apple.com/. There doesn't seem to be anything wrong with nodogsplash itself — according to the logs, it's trying to serve the splash page. One difference is that with the first url (captive.apple.com), I see several requests being captured as 404 requests. But the second url captures a single index request. I've pasted a snapshot of the logs here:
Sat Jul 14 06:59:05 2029 daemon.info nodogsplash: Creating httpd request thread 1 for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Thread 1 calling httpdProcessRequest() for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.info nodogsplash: Capturing index request from 192.168.1.143 for [netcts.cdn-apple.com/]
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Locking client list
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Client list locked
Sat Jul 14 06:59:05 2029 daemon.notice nodogsplash: Adding 192.168.1.143 64:c7:53:57:15:61 token e2e3c96b to client list
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Unlocking client list
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Client list unlocked
Sat Jul 14 06:59:05 2029 daemon.info nodogsplash: Serving splash page /etc/nodogsplash/htdocs/splash.html to 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Thread 1 returned from httpdProcessRequest() for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash: Thread 1 ended request from 192.168.1.143
Sat Jul 14 06:59:22 2029 daemon.debug nodogsplash: Running fw_refresh_client_list()
The only possible cause of this that I can think of is Apple has recently changed how they perform the captive portal detection with the second url netcts.cdn-apple.com.
I've tried a bunch of different things like forwarding the domain cdn-apple.com to the router gateway (192.168.1.1) or another internet address using dnsmasq or a hosts file. I also tried forwarding it to a local web application that returns a 404 response code, but no luck. Unfortunately, I think I'm out my depth here.
Unfortunately, you are using nodogsplash, which I am not familar with, as I am using coova-chilli, only. But from your post I can read, you might have serious misunderstanding, how the CP should work. I.e. "404 requests" indicate wrong handling, in general. BTW: What is an "index request" ?
Like already mentioned, better to ask your nodogsplash-specific question in their forum, as it has nothing to do with openwrt.
Thanks for the responses everyone! I'll ask about this on the nodogsplash github page, and perhaps also look into fakeinternet or coova-chilli, if that changes things. Please let me know if there are any other things I can try.
@reinerotto the 404 and index requests are coming from the nodogsplash logs. To be honest, I'm not entirely sure what they refer to either. Just thought it's worth pointing out that the requests for the two URLs appear to be captured differently.
NoDogSplash does a 307 Temporary Redirect, so I can't see where the 404 is coming from.
The current release of NoDogSplash is v4.3.3, and @ramkumars is using v1.01 so I have suggested an upgrade as the first step.
For anyone following, see:
First of all, I suspect a problem regarding your "walled garden" entries (uamallowed etc.).
But as your question is not openwrt-specific, and has the strong indication to be a commercial system, I am sorry to say, not to provide detailed research for free. As I am doing such systems for a living
I found the bug in Alvin Jose's system. After few hours of debugging he not even cares to say thank you. To expect help here on the forum free of charge for a commercial system seems to be common now. The bug is not to care about restrictions on the captive portal . Valid on iOS only no problem on Android.
It's not like escaping from the topic. Actually I've ordered an OpenWRT device nano pi R1, and waiting it to get delivered. Definitely I would required support and it will be perfect at the presence of an OpenWRT device.