[RADIATOR] Beginners question : How to construct a Handler rule that explicit filters out non EAP requests

[Hugh Irvine]

Hello Anders, Hello Alex -

I tend to agree with Alex - I always find it preferable to set up my configuration files with matches.

There are two reasons for this: first the way Radiator works - first match is the only match with Handlers, second (and more important)  it is much easier to understand.

Another approach I frequently tend to use is multiple instances of Radiator - ie: a "front end" to classify the requests, together with multiple "back ends" to deal with the different types of requests (or different user groups, or different realms, or whatever).

regards

Hugh


On 26 Nov 2009, at 06:54, Anders Nilsson wrote:

> Hi again,
> 
> Sorry for missing to repost to the list. 
> I'm in shame will try to better myself. ;)
> 
> Well in my case I'm using a Radius server to loadbalance an open wlan by MAC-authetication and loading the on to different VLAN:s. beides that I'm webauthenticating web portal users and I yes there will be some EAP handling also but I still find it a bit awkward that that a check like this is not available. In my humble opinion it would be nice to check for the absence of a attribute or value.
> 
> Maybe it just me and maybe I have to settle for carefully arranging my Radiator configuration file.
> 
> 
> Thanks anyway for your reply Alex. At you gave me another angle to the problem.
> 
> 
> Cheers
> Anders Nilsson
> 
> 
>> -----Ursprungligt meddelande-----
>> Från: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au]
>> För Alexander Hartmaier
>> Skickat: den 25 november 2009 19:06
>> Till: radiator at open.com.au
>> Ämne: Re: [RADIATOR] Beginners question : How to construct a Handler rule
>> that explicit filters out non EAP requests
>> 
>> Hi Anders!
>> 
>> You should mail to the list too.
>> 
>> So you don't won't to match EAP requests at all?
>> I suggest to do a Handler for EAP requests and put a default reply in
>> it, reject for example, and after it the Handler you want for non-EAP
>> requests.
>> 
>> If your radiator receives EAP requests you should handle them.
>> 
>> --
>> Best regards, Alex
>> 
>> 
>> Am Mittwoch, den 25.11.2009, 18:59 +0100 schrieb Anders Nilsson:
>>> Hi
>>> 
>>> Thank you for the quick reply but that doesn't quite answer my question
>> rather makes a work-around of the problem. Does anyone else have an idea
>> on what to put in the Handler?
>>> 
>>> 
>>> Cheers
>>> Anders
>>> 
>>>> -----Ursprungligt meddelande-----
>>>> Från: radiator-bounces at open.com.au [mailto:radiator-
>> bounces at open.com.au]
>>>> För Alexander Hartmaier
>>>> Skickat: den 25 november 2009 18:36
>>>> Till: radiator at open.com.au
>>>> Ämne: Re: [RADIATOR] Beginners question : How to construct a Handler
>> rule
>>>> that explicit filters out non EAP requests
>>>> 
>>>> Insert another handler after this one matching the same realm.
>>>> Remember that the order of handlers makes a difference as Radiator
>> uses
>>>> the first matched Handler.
>>>> 
>>>> --
>>>> Best regards, Alex
>>>> 
>>>> 
>>>> Am Mittwoch, den 25.11.2009, 17:05 +0100 schrieb Anders Nilsson:
>>>>> Hi,
>>>>> 
>>>>> 
>>>>> 
>>>>> I'm sure that this is a typical case of RTFM but here goes anyway:
>>>>> 
>>>>> 
>>>>> 
>>>>> If you in a Handler want to process only EAP requests you construct
>>>>> something like this:
>>>>> 
>>>>> 
>>>>> 
>>>>> <Handler  Realm= /(.*\.umu.se)/I , EAP-Message=/.+/>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Now my question how to negate this in a Handler.
>>>>> 
>>>>> How do I process only non-EAP Radius requests?  What check item do I
>>>>> use and how does a typical Handler look?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> Anders Nilsson
>>>>> 
>>>>> Umeå University
>>>>> 
>>>>> SUNET Sweden
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"
>>>> *"*
>>>> T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
>>>> Handelsgericht Wien, FN 79340b
>>>> 
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"
>>>> *"*
>>>> Notice: This e-mail contains information that is confidential and may
>> be
>>>> privileged.
>>>> If you are not the intended recipient, please notify the sender and
>> then
>>>> delete this e-mail immediately.
>>>> 
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"
>>>> *"*
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.