Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A DHCP option would be the correct way to specify a captive portal on a LAN. We have DHCP options for tons of things: IP phones, TFTP servers, cable boxes. One more option for a captive portal authentication URL would properly inform clients that there is a captive portal and how to access it. (It being a URL means it can also specify the protocol, so you aren't even locked into web browsers)

My assumption is this wasn't adopted because operators want the option of placing the captive portal upstream of the local network DHCP server. DNS spoofing works great over multiple network hops, but DHCP doesn't. (I'm not sure if that's a valid argument, but I'm sure somebody insisted on it)




There is a DHCP option for a captive portal URL. It isn't very well supported and nobody uses it.

https://datatracker.ietf.org/doc/html/rfc7710



If they got the top 5 wifi router vendors to support it, for sure you'd see other clients support it too, because the whole point of captive portal support in browsers is to react to what those routers are doing for captive portaling.

Since those vendors largely use open source tools, if you patched open source DHCP servers with that option, it would get adopted quicker by them.

- KEA DHCPD supports it as option 114: https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/li...

- ISC DHCPD is officially ended (whoa!), but it looks like it supports option 114: https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/commo...

- Dnsmasq author says they added the option (https://www.mail-archive.com/dnsmasq-discuss@lists.thekelley...) but I don't see it in their latest release

- Udhcpd doesn't seem to support it, so somebody could send them a patch, looks trivial to add




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: