Dinesh Nair wrote:
> On Sun, 23 May 2004, Manuel Kasper wrote:
>>The captive portal just got better: we now have RADIUS authentication
>>support, thanks again to Dinesh Nair! By specifying a RADIUS server,
> and with thanx to jason grimm for providing a radius server to test
>>port and shared secret, as well as adding two input fields
>>(user/pass) to your captive portal page, you can have your users
> the input fields should be named auth_user and auth_pass. if the radius
> server auth is enabled and if either of these two fields dont exist, then
> radius authentication will always fail. this could be used to implement
> simple mac filtering (though non-foolproof) behind the captive portal.
So, if I were to enter some bogus ip/secret/etc in the radious
settings (to enable radius server auth, even if i don't have such a
server), and omit the fields on the portal page (so no actual auth
requests will be sent to my non-existent server), I'd effectivly have
MAC filtering with a nice "Error" page shown to those not listed in
among the allowed MACs?
I find this a very nice "feature" (side effect?) Since it will allow
me to do MAC filtering AND displaying a legalese "scare crow" page to
anyone not on the list trying to get through ;)
> in addition to this, the captive portal allowed ip functionality now
> allows specification of IPs on both sides of the captive portal.
> specifying From IPs would mean that clients with this IP address would
> bypass the captive portal authentication, while specifying To IPs would
> mean that all unauthenticated clients would be able to access these IPs
> from behind the captive portal.
Is it still necessary for any clients with "From IPs" to start their
WAN sessions with a http request to get through?
If so, any chance this will change in the near future?