chilli features...

[wlan at mac.com]

Hello all,

I have some ideas for new chilli features and wanted to run them by  
the mailing list and ask for comments.

Right now, when you use MAC authentication, if an access-reject is  
returned, the user will still get assigned an IP address and will  
then be given the captive portal. This is good as a way to have  
certain devices bypass the captive portal. But, it would also be nice  
to use MAC authentication as a way to manage blocked devices. I'm  
considering an option which will have chilli drop all traffic from  
clients that get an access-reject during mac authentication. When  
clients are in the 'drop' state, all traffic from them is ignored.

There have been some requests in the forum for a less restrictive  
"splash page" feature. Of course, you can already do this with some  
coding in the landing page to auto-login the user with some pre- 
configured username and password. Though, I think it would be nice to  
have another authentication state -- where the client has access to  
the Internet (on all ports except port 80), but still gets redirected  
to a splash page when trying to browse non-SSL websites. From the  
splash page, the user will have to 'login' again (or have some  
scripting do this automatically). Sessions will be put into the  
'splash' state either by an Access-Accept with the option indicated  
in an attribute during MAC authentication or using chilli_query from  
the command line. In either case, a specific splash page URL can also  
be provided -- as a means to send users to potentially different  
splash pages.

The splash page feature when combined with mac-auth really becomes a  
two-stage authentication process... kinda like the "WPA Guest"  
feature that is already implemented. The 'first' stage is either mac- 
auth or WPA and the 'second' stage being the captive portal. From an  
accounting perspective, it may be nice to have accounting of the  
first stage "session" being separate from the second stage. This way,  
you could know the usage of a client before and after the second  
stage authentication. There are two ways of doing this: either the  
first and second stage session's accounting overlaps or the first  
stage session is stopped when the second stage session starts. If the  
sessions overlap, the Acct-Multi-Session-Id could be used to link  
together the two RADIUS sessions.

Any comments or suggestions are welcome!

David