users match list criteria and vendor identification

[Cameron Wood]

In the clients.conf file is it possible to make custom variables and then
test for those/match them in the users file?

What I'd like to do is create a variable called vendorname and use that to
dictate what stub in the users file gets hit depending on the make/platform
of the equipment in question, and then further filter that using huntgroups.



Can anyone tell me if any of that is possible?


Cheers
Cam.
--







On Thu, Sep 23, 2010 at 09:16, Cameron Wood <cameron.e.wood at gmail.com>wrote:

> Thanks for the reply.
>
> Resigned to the fact that I will have to distinguish my vendors/devices in
> the clients.conf file, is there a way in this file to put multiple hosts in
> a single statement, other than by using a netmask?
>
>
> Cheers
> Cam.
> --
>
>
>
>
>
>
> On Wed, Sep 22, 2010 at 17:46, Phil Mayers <p.mayers at imperial.ac.uk>wrote:
>
>> On 09/22/2010 08:12 AM, Cameron Wood wrote:
>>
>>> Does Freeradius have a way for me to see the packet sent to it?
>>>
>>> I've already tried running it with the -X flag, but that isn't showing
>>> enough detail.
>>>
>>
>> That's all the detail there is. FreeRadius shows the full packet as it is
>> received; what more should it show?
>>
>> In answer to your question, no, most NASes don't send a vendor ID.
>> Sometimes they send VSAs, so you can infer the vendor from those, but other
>> times you'll get near-identical requests from two different NASes, and if
>> you want to tell them apart (so that you know which one to send VSAa back
>> to) you have to use different "clients {}" blocks and go from there.
>>
>> It's a shame the original radius specs didn't include a vendor ID, but
>> that can be said about a lot of attributes - it's an old (venerable)
>> protocol.
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100923/c9de8538/attachment.html>