DHCP Option 114 and 160 for Captive Portal

Installing and Using OpenWrt
1

Captive Portal handling by smartphones has evolved from Wispr (2010) and then to RFC7710 (2015) and now RFC8910 (2020) https://datatracker.ietf.org/doc/rfc8910/

Section 4.1 describes the Captive Portal Unrestricted Identifier which can be used to indicate a captive portal is NOT present to smart clients that may have otherwise been on a captive portal network prior to receiveing their current DHCP lease.

To implement this, we tried the following in the /etc/config/dhcp

config dhcp 'lan'
	list dhcp_option '114,urn:ietf:params:capport:unrestricted'

Which shows up in /var/etc/dnsmasq.conf after being applied as

dhcp-option=lan,114,urn:ietf:params:capport:unrestricted

However, the option is not served up, as seen in the tcpdump output, where we successfully used the same syntax to pass

list dhcp_option '15,test.com

13:42:22.092393 IP (tos 0xc0, ttl 64, id 36288, offset 0, flags [none], proto UDP (17), length 330)
    pf4-user.lan.67 > iPhone.lan.68: [bad udp cksum 0x1e1b -> 0x9248!] BOOTP/DHCP, Reply, length 302, xid 0xe3243e79, Flags [none] (0x0000)
	  Your-IP iPhone.lan
	  Server-IP pf4-user.lan
	  Client-Ethernet-Address 2c:be:08:8e:37:d8 (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: pf4-user.lan
	    Lease-Time Option 51, length 4: 43200
	    RN Option 58, length 4: 21600
	    RB Option 59, length 4: 37800
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    BR Option 28, length 4: 10.2.4.255
	    Default-Gateway Option 3, length 4: pf4-user.lan
	    Domain-Name-Server Option 6, length 4: pf4-user.lan
	    Domain-Name Option 15, length 8: "test.com"
	    END Option 255, length 0

We had no luck with Option 160 either.
Is there a way to use these DHCP options with OpenWRT; Maybe an alternate configuration directly with DNSmasq or possibly a different dhcp client?

I see some references that suggest it may have been possible in the past Dhcp option 160 - #5 by mk24

It seems odd to me that these DHCP WiFi options would not be supported by the server given they are not that new

Any help or insights appreciated

1 Like
2

We quickly learned, with these options, you have to use the dhcp_option_force as the client is not requesting them.

list dhcp_option '15,test.com'
list dhcp_option_force '114,urn:ietf:params:capport:unrestricted'

Which is now working for us.

14:12:09.504188 IP (tos 0xc0, ttl 64, id 24199, offset 0, flags [none], proto UDP (17), length 368)
    pf4-user.lan.67 > iPhone.lan.68: [bad udp cksum 0x1e41 -> 0x6109!] BOOTP/DHCP, Reply, length 340, xid 0xe3243e7a, Flags [none] (0x0000)
	  Your-IP iPhone.lan
	  Server-IP pf4-user.lan
	  Client-Ethernet-Address 2c:be:08:8e:37:d8 (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: pf4-user.lan
	    Lease-Time Option 51, length 4: 43200
	    RN Option 58, length 4: 21600
	    RB Option 59, length 4: 37800
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    BR Option 28, length 4: 10.2.4.255
	    Default-Gateway Option 3, length 4: pf4-user.lan
	    Domain-Name-Server Option 6, length 4: pf4-user.lan
	    URL Option 114, length 36: "urn:ietf:params:capport:unrestricted"
	    Domain-Name Option 15, length 8: "test.com"
	    END Option 255, length 0
1 Like
3

Thank you for posting the following up on that issue and linking related doxuments! This also nice knowledge for "under estimated knowledge for 400"!

4

This is not the full story and is a bit of a misleading statement.
The two main vendors of mobile client device operating systems developed the de-facto Captive Portal Detection (CPD) standard. This is driven by the client device using probing, or "canary testing" resulting in a redirect to the portal splash page sequence. This has evolved since ~2010 to become the reliable, mature and universally supported standard.
Currently, all modern operating systems have built in GUI support for CPD - including OS for all mobiles, laptops, desktops.

CPD is not perfect, one of the most common issues occurs due to long probe intervals on mobiles to conserve battery. There are other issues also, mainly the lack of indication of captive portal presence to the end user until the login page pops up.

Over a number of years, there has been slow progress to develop a new standard, culminating in the RFC8910/RFC8908 Captive Portal Identification (CPI) standard of 2020.

Since 2020, client device vendor implementation has been very slow, and likewise, captive portal vendors/developers have also been slow to move, for the reason of "we don't need to because clients do not support it".

What we are possibly seeing though is the very early beginning of a typical S curve of change as more and more new mobile devices have at least a rudimentary support (quite possibly untested due to the lack of supporting CPs).

As CPI support is added in more clients and CPs, we will see a maturing of the implementations, but so far it looks likely that it could be some time before CPI "takes over".

You can read a bit more about this here:
https://opennds.readthedocs.io/en/latest/howitworks.html#captive-portal-detection-cpd

1 Like
5

Sorry, it was not my intention to provide a [full] story. But why not; I have learned a few things about Option 114 using dnsmasq to test how IOS clients handle the value.

Adoption is always slow. OpenNDS does a great job explaining how Captive Portals work. I found it quickly researching Option 114 use with IOS, and aims to implement more of the newer standards than most other solutions. Looks lightweight and great to fill the void left from CoovaChilli I used years ago for coffee shop style implementations. Looking forwards to testing it out some day.

Packetfence has a great implementation I have now been using for the last decade, but you are going to use it, you really need to understand your networking and have a server to run it on, as the Captive Portal implementation is just a small part of the full blown NAC solution. It works with hostapd/OpenWRT which lead me to investigating Option 114 to workaround iPhones current CPI implementation quirks which require special handling as they begin to support newer RFCs more completely.

The two main platforms, being IOS and Android, do support CPI to some extent and Wispr previously and I have never found a standard "CPD" published anywhere. What OpenNDS calls CPD, is support for common detection URLs which can present a LogIn Page (i.e. captive.apple.com) where the capitve portal implementation can implement javascript to do all kinds of interesting things, like registration, terms acceptance, network detection, redirection, etc.

The IOS implementation is a bit quirky, which is why I was investigating Option 114 on dnsmasq for some test cases.

Unfortunately, in CPD, once IOS starts its login page, no matter what happens, it uses the CPI defined Option 114 URL for network detection after it has left the captive portal, even if the network is has been switched to advertises the RF8910 CPI value for unrestricted in Option 114.

If you are operating over a larger geographic area, not inline (say a bunch of schools) and want to use the same hostname for Captive Portal login and also to do anything else after leaving the Captive Portal, i.e. Activation link for extended use, client status, etc. the IOS implementation will cause you a headache, using the CPD method in combination with the CPI Option 114 API URL.

You have to not use Option 114 in order to use that CPD embedded network detection and be able to return to your Captive Portal URL in a non-inline topology.

That is why I wanted to test this dhcp option. To try and work around the IOS half-baked CPI implementation. But IOS completely ignores it, on a different network, after initial detection in a Captive Portal environment.

Some related links on CPI use in IOS
https://developer.apple.com/forums/thread/660827

Here are the standards

2 Likes
6

Dear Imac, I am a total newbie on coovachilli and openwrt.

I have installed coovachilli and my iphone does not show the splash page.

Could you please explain how you make the dhcp-option 114 active for captive portal users.

Thanks