Captive portal solution - identify known/unknown clients
Problem The use case is, to have a list of MAC addresses that are known subscribers, but allow anyone to connect to the DHCP service. Every known valid customer would have a reservation, any devices without a reservation would be not yet subscribed or authorized for service. (The 'invalid user' might be a user who has connected to the network but not yet subscribed, or a user who has discontinued their service or is not currently paying.) The 'unknown' or 'invalid' users would be directed to a captive portal to register for service.
This is what the user_chk hook did, but it hasn't been maintained and is considered only an 'example' hook. What we need is a solution that is deployable at scale for a service provider.
Proposed solution One way to do this would be by doing a global host reservation for every 'known' subscriber that will just set the known/unknown option to known (and then this known/unknown information can be assessed in subsequently selecting a subnet). This doesn't work currently.
It would be ideal if the (global) HR has only a single mandatory field: MAC address. The IP address or hostname or other options should all be .... optional.
At the moment, the HR has to specify a hostname or IP address. These are cable endpoints, so we don't need a hostname, and we don't want to force a specific IP address (this should be optional, not required). It would likely be the case that unknown clients would get IP addresses from a different pool that might restrict their connectivity.
We don't want to set any options in the HR. If a reservation is found for the client, then it should be classified as 'known'.
Another solution would be to re-implement the user-chk hook. I have been telling people this was the captive portal solution for a while, but as now we think it isn't scalable... we could just re-implement it.