chilli features...

wlan at wlan at
Sun Feb 10 06:54:49 UTC 2008

Hi, and thanks for your feedback.

I have been working with the feature, but it still needs more testing  
before I put it in the wild.

Your suggestion for using the Reply-Message is a good one. Though,  
might as well use a different attribute; probably a new chilli VSA.

'Sessions' are maintained in chilli, subject to various timeouts for  
dhcp lease, idle timeout, etc. So, sessions (or 'connections', as  
referred to in the code) are handled the same way - keyed on the  
client's MAC address. When a session is in drop state, of course, all  
packets are immediately dropped until the session gets cleared.  
Perhaps it would be an idea to set a specific time period for this  


On Feb 9, 2008, at 8:08 PM, JB wrote:

> Hi,
> I just stumbled across this idea for a new feature for CoovaChilli:
> wlan at wrote:
>> 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.
> I think that would be a great feature! Or has this been already  
> implemented? If not, here are my two cents:
> Why not (mis)use the Reply-Message attribute from RADIUS to achieve  
> this? If the value of Reply-Message is a certain "code", like  
> "chilli:drop", then Chilli knows it should ignore all further  
> requests from this MAC address. Basically, there would be three  
> ways to handle a response from an Access-Request request (apart  
> from errors or the like):
> Access-Accept -> UAM "success"
> Access-Reject and Reply-Message is not "chilli:drop" -> UAM "failed"
> Access-Reject and Reply-Message is "chilli:drop" -> Drop request(s)
> This way, we would neither break the current behaviour nor the  
> RFCs. No need to turn this feature on or off in chilli because the  
> logic (maybe along with black-/white-lists) resides in the RADIUS  
> server.
> Would there still be some sort of session handling? How long would  
> chilli drop requests until it "asks" RADIUS again?
> JB
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: chilli-unsubscribe at
> For additional commands, e-mail: chilli-help at
> Wiki:
> Forum:

More information about the Chilli mailing list