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
> against.
> 
> 
>>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?


Adam.