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