chilli features...

sophana sophana at
Sun Feb 10 22:33:38 UTC 2008

I think the reply message is not a very good idea. As david say, it WILL 
be shown to the user. That's it.
Having an unknown attribute in a message does not bother anyone, as it 
will simply be ignored by all software that don't know about it.

JB a écrit :
> Counterquestion: Why would an administrator or developer 
> activate/implement the "chilli:drop" response, although there is no 
> Chilli in use at all? I still think that Reply-Message would perfectly 
> suit our needs, but don't get me wrong: While I also think that RFC 
> compliance is very important, if having this feature in one of the 
> next releases means to add a CoovaChilli VSA, that's fine with me.
> Just let me know if I can be of any assistance.
> JB
> wlan at (10.02.2008):
>> Admittedly, it wouldn't be the first time I've gone outside the scope 
>> of the noted RFCs for vendor specific features. While I agree RFC 
>> compliance is important and should be maintained as much as possible, 
>> I also believe RADIUS is now being used for more than it was intended 
>> and bending the rules are sometimes necessary. My opinion is that 
>> it's better to interoperate with RFC compliant vendors rather than 
>> being RFC compliant yourself. Meaning, if a non-chilli RADIUS client 
>> got an Access-Reject with a Chilli VSA, I doubt it would care much. 
>> But, if given an Access-Reject with reply-message "chilli:drop", 
>> it'll likely show this message to the user. What is better, changing 
>> the meaning of an attribute for a feature or extending RADIUS (which 
>> was designed to be extendable)? I suppose the right answer is to 
>> raise these issues in the working group, which could happen, but that 
>> doesn't mean it can't be tried and tested first.
>> That notwithstanding, one could argue the extra VSA fits into the RFC 
>> 5080 clause:
>>         Attributes within an Access-Reject are
>>    restricted to those necessary to route the message (e.g., Proxy-
>>    State), attributes providing the user with an indication that access
>>    has been denied (e.g., an EAP-Message attribute containing an EAP-
>>    Failure), or attributes conveying an error message (e.g., a Reply-
>>    Message or Error-Cause attribute).
>> Ok, not really, but maybe a little.
>> David
>> On Feb 10, 2008, at 9:44 AM, JB wrote:
>>> Hi,
>>> you're welcome.
>>> I guess using a chilli VSA would break the RADIUS RFCs, which say 
>>> that only very few attributes are allowed in an Access-Reject 
>>> response ([1] and [2]). Reply-Message is one of them.
>>> You're right, having an optional parameter like "droptimeout" is 
>>> probably a good idea. Not sending a "normal" Access-Reject (with an 
>>> explanatory message) means that nothing good came from this MAC 
>>> address. Administrators may like to block them for a longer period 
>>> than the normal session/dhcp/idle timeouts without increasing the 
>>> load of the RADIUS server or its database backend.
>>> Just let me know if I can help testing this feature.
>>> JB
>>> [1]
>>> [2]
>>> wlan at (10.02.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 
>>>> state.
>>>> David
>>>> 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