Captive portal problem — nodogsplash captive portal sometimes not displaying on iOS

Installing and Using OpenWrt
1

Hi,

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:

  1. captive.apple.com/hotspot-detect.html and
  2. netcts.cdn-apple.com/

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[1520]: Creating httpd request thread 1 for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Thread 1 calling httpdProcessRequest() for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.info nodogsplash[1520]: Capturing index request from 192.168.1.143 for [netcts.cdn-apple.com/]
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Locking client list
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Client list locked
Sat Jul 14 06:59:05 2029 daemon.notice nodogsplash[1520]: 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[1520]: Unlocking client list
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Client list unlocked
Sat Jul 14 06:59:05 2029 daemon.info nodogsplash[1520]: Serving splash page /etc/nodogsplash/htdocs/splash.html to 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Thread 1 returned from httpdProcessRequest() for 192.168.1.143
Sat Jul 14 06:59:05 2029 daemon.debug nodogsplash[1520]: Thread 1 ended request from 192.168.1.143
Sat Jul 14 06:59:22 2029 daemon.debug nodogsplash[1520]: 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. :confused:

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.

OpenWRT version from /etc/openwrt_release

DISTRIB_ID='LEDE'
DISTRIB_RELEASE='17.01.6'
DISTRIB_REVISION='r3979-2252731af4'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_ARCH='arm_cortex-a9_vfpv3'
DISTRIB_DESCRIPTION='LEDE Reboot 17.01.6 r3979-2252731af4'
DISTRIB_TAINTS=''

iOS version on my test device (if that's relevant): 13.1.3

Has anybody else encountered this issue before? Any help will be much appreciated!

Thanks!

2

I would ask this question directly to the nodogsplash people.

3

take a look at stangri's fakeinternet

4

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.

5

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.

6

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:

2 Likes
7

Thanks @bluewavenet! I'll give this a go and report back on the github issue.

8

Hi Reinerotto,
I'm using coovachilli and Im not getting CP pop up after completing forst CAP on iphones. but it works perfectly in android devices. Can you please suggest something???

9

What is this ?
Pls, also provide your "walled garden" entries.

10

I mean data CAP(sorry for the typo). we are setting the user to access only 500MB data. after that the captive portal should POP up again and he have to do login with email id and password.

11

Also as a walled garden I'm giving below line in config file of chilli.
"HS_UAMALLOW=www.appleiphonecell.com,.apple.com,www.itools.info,www.book.info,www.airport.us,www.thinkdifferent.us,.apple.com.edgekey.net,.akamaiedge.net,.akamaitechnologies.com"

12

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 :slight_smile:

13

Thats Okey. How can I contact you?

14

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.

1 Like
15

He was busy engaging me too - now I see he hijacked this thread; and sent you Private Messages also:

Thanks for noting to the community that this is a commercial system that support is being sought for.

16

Dear Team,
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.

17

Please select one thread for discussing your issue. Thanks.

Your statement doesn't address the concern; but sure.

It's kinda rude to make 2 threads on the same topic and hijack a third...don't you think?

18

I didnt create any multiple profiles or threads for my issues. It may be your misunderstanding.. Kindly recheck it.
Thank you.

1 Like