Re: [RADIATOR] Some information lost during Diameter to Radius conversion
31.03.2014 16:16, Heikki Vatiainen kirjutas:
> On 03/31/2014 10:30 AM, Arthur wrote:
>
>>SDP-Session-Description: VM., v=0
>>SDP-Session-Description: VM., o=- 640284584 403958478 IN IP4
>> 94.50.86.245
>>SDP-Session-Description: VM., s=-
>>SDP-Session-Description: VM., c=IN IP4 94.50.120.5
>>SDP-Session-Description: VM., t=0 0
>>
>> I have tried to add the following code to my hook for enumerating all
>> entries and making fake attributes like 'SDP-Session-Description-n':
>>
>> my $ims_info = $si->get_attr(876, 10415); # IMS-Information (grouped)
>> my $nn;
>> if (my @avpair = $ims_info->get_attr(842, 10415)) { #
> Try get_attrs() instead of get_attr(). This Diameter attribute list
> works differently here, that is, get_attr does not check if the caller
> expects a list or a single value.
Thanks, much better now.
One mystery (or bug?) needs explaining, though.
I have the following Diameter request part:
Wireshark:
AVP: Ericsson-Service-Information(285) l=264 f=V-- vnd=Ericsson
AVP: MMT-Information(1061) l=224 f=V-- vnd=Ericsson
AVP: Calling-Party-Address-Presentation-Status(1141) l=16 f=V--
vnd=Ericsson val=0
AVP: Called-Asserted-Identity-Presentation-Status(1142) l=16
f=V-- vnd=Ericsson val=0
AVP: SIP-Ringing-Timestamp-Fraction(1256) l=16 f=V-- vnd=Ericsson
val=437
AVP: From-Header(1153) l=82 f=V-- vnd=Ericsson val="3000"
;tag=h7g4
AVP: From-Header-Presentation-Status(1262) l=16 f=V--
vnd=Ericsson val=0
AVP: Service-Number-Type(1307) l=16 f=V-- vnd=Ericsson val=2
Radiator 4.12.1 debug log:
Ericsson-Service-Information: V..,
MMT-Information: V..,
Calling-Party-Address-Presentation-Status: V.., 0
Called-Asserted-Identity-Presentation-Status: V.., 0
SIP-Ringing-Timestamp-Fractions: V.., 437
From-Header = ""3000" ;tag=h7g4"
From-Header-Presentation-Status: V.., 0
Service-Number-Type: V.., 2
And with hook's construction like:
if (my $eee_info = $d->get_attr(285, 193)) {
if (my $mmt_info = $eee_info->get_attr(1061, 193)) {
if (my $caips = $mmt_info->get_attr(1141, 193)) {
$r->add_attr('Calling-Party-Address-Presentation-Status', $caips);
}
}
}
works only with "Service-Number-Type" and "From-Header" AVP converting.
To make converting to work I had to modify hook's construction to:
if (my $eee_info = $d->get_attr(285, 193)) {
if (my $mmt_info = $eee_info->get_attr(1061, 193)) {
if (my @caips = $mmt_info->get_attrs(1141, 193)) {
$r->add_attr('Calling-Party-Address-Presentation-Status', @caips[0]);
}
}
}
Is there any logical explanation?
br,
Arthur
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2014-03-28 09:02, Hartmaier Alexander wrote:
> On 2014-03-27 20:43, Heikki Vatiainen wrote:
>> On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:
>>
>>> Did you have time to work on this feature?
>> We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
>> not this. It's still on the ideas to explore list, though.
>>
>>> I've started tring to get all Radiator logs into Elasticsearch via
>>> RabbitMQ and found out that also closes the pipe in case of
>>> Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
>> It makes the log files easy to rotate, but I can see why it's not good
>> in this case.
> Because the logging script has some quite a 'high' startup time because
> it has to connect to RabbitMQ and also disconnects immediatly afterwards
> causing quite some overhead and RabbitMQ logging.
>>> The comment in Radius::Util::append says:
>>> # Current implementation opens, writes and closes
>>> # Future implementations might hold the file open, and reopen on
>>> # signal, or perhaps pipe to a daemon
>>>
>>> I need a feature that keeps the spawned (forked?) process open and pipe
>>> to it.
>>> I'd also need to escape the log message so my JSON doesn't break in case
>>> the message contains one or more ".
>>>
>>> LogFormat { "timestamp":"%Y-%m-%d %H:%M:%S", "priority":"%1",
>>> "message":"%2" }
>> Hmm, maybe a new class that could be configured to support the above? It
>> would need to be able to quote the log messages, maybe a configurable
>> method for different kinds of destinations (JSON, etc), hold the fd open
>> while supporting FarmSize and possibly something else too. I'd say
>> extending Log FILE may not be a good idea but to have a new logging class.
>>
>> If you already have something that does what you require on the > ...> side, please get back to me directly.
> Yeah, I was thinking about writing a LogMessagePassing or Log4perl class
> but am not sure to which api I have to follow as its internal and as far
> as I know undocumented.
> For now I've created a named pipe which I configured Radiator to log to
> and have a Message::Passing DSL script that runs as daemon using
> Daemon::Control which uses the TailFile input and the AMQP output.
> I wanted to not have to run that extra daemon because it's one more
> thing that can go wrong.
I need a solution that outputs structed log messages serialized as JSON
fast.
My quick solution is:
# this is a named pipe created using mkfifo
Filename %L/radiator.fifo
LogFormat { "timestamp":"%Y-%m-%dT%H:%M:%SZ", "source_host":"%h",
"priority":"%1", "type":"radiator",
"customer":"%{OSC-Customer-Identifier}", "message":"%2" }
Trace 3
The problem is that some messages contain linefeeds (openssl library
errors when using EAP-TLS for example) which don't get escaped as per
JSON spec and make the JSON parsing fail.
I think extending LogFormat is the right way to go because one might
want to log to a file or database in json or yaml as well.
What I still haven't figured out is a config format.
Enabling to pass a Perl sub to LogFormat would be the most flexible
option but not the most user friendly.
Ideas?
>
>> Thanks,
>> Heikki
>>
>>
>
>
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> 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@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Some information lost during Diameter to Radius conversion
On 04/01/2014 02:12 PM, Arthur wrote: > One mystery (or bug?) needs explaining, though. > I have the following Diameter request part: Can't really say why you need to use get_attrs. What does your dictionary have for MMT-Information and Calling-Party-Address-Presentation-Status? Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Some information lost during Diameter to Radius conversion
1.04.2014 17:33, Heikki Vatiainen kirjutas: > On 04/01/2014 02:12 PM, Arthur wrote: > >> One mystery (or bug?) needs explaining, though. >> I have the following Diameter request part: > Can't really say why you need to use get_attrs. What does your > dictionary have for MMT-Information and > Calling-Party-Address-Presentation-Status? File diameter_attrs.dat has for those AVP's: VENDORATTR193MMT-Information1061 Grouped VENDORATTR193Calling-Party-Address-Presentation-Status 1141 Unsigned32 To be honest by documentation Calling-Party-Address-Presentation-Status AVP described as Enumerated. But I don't need to translate it to the text values. AVP Service-Number-Type, which decoded correctly by get_attr has the same state regarding documentation: VENDORATTR 193 Service-Number-Type 1307 Unsigned32 #Enumerated Any ideas? May be you need a complete tcpdump for analysing? br, Arthur ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Preventing Computer/Machine Authentication in AuthBy NTLM
Hi Heikki,
Thanks for your input, this mailing list has always been extremely helpful.
I attempted to implement your suggestions on items 1 and 2. 1 is
straightforward, but I'm still a bit puzzled by 2. I looked at eap_peap
and eap_multi in goodies to get an idea of what to do. Using your
comments and the docs, I made some changes, adding two inner request
handlers, one for PEAP and one for TTLS. I tried implementing the Hook
but my NAS still reports the wrong user if I put some random username in
the 'anonymous identity' field on my wireless client.
Topic 3, the SSO stuff is a ways a away, but I will write the list with
any insight I have once I attempt it.
Here's my config:
## ##
# Radiator Configuration #
# ##
## Updated 4/1/2014
## Note this file is derived from pre-testing version provided by
mrodrigues
#This handler catches all "Accounting-Request" packets.
#We only log Start and Stop accounting packets as Alive
#packets are basically useless for our purposes. If you
#would like to grab these packets, delete the "HandleAcctStatusTypes"
#directive below, or edit as obviously necessary.
#
#
#DBSourcedbi:mysql:radius:127.0.0.1:3306
#DBUsername radius
#DBAuth xxx
#HandleAcctStatusTypes Start,Stop
# This statement inserts the accounting information into the SQL databasee.
#AcctSQLStatement insert into ggse_public
values('%{Acct-Session-Id}','%{Framed-IP-Address}','%{User-Name}','%{Acct-Status-Type}','%{Extreme-SSID}','%{Connect-Info}','%{Acct-Delay-Time}','%{Timestamp}','%{Calling-Station-Id}',NULL);
# This will log messages from within the SQL insert statement
#
#Filename debug.config
#
#
#
#below was added on 2/4/13 to catch ALL iterations of logins that are
BlackListed.
RewriteUsername tr/A-Z/a-z/
#These are the subnets from which calls to the RADIUS server are allowed.
Secret testing123
DupInterval 0
# AuthBy INTERNAL will reject here
# This catches computers trying to auth
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPTypeMSCHAP-V2
#EAPTLS_CAFile /etc/radiator/certs/demoCA/cacert.pem
EAPTLS_CAFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_interm.cer
#EAPTLS_CertificateFile /etc/radiator/certs/cert-srv.pem
EAPTLS_CertificateFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_cert.cer
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/cert-srv.pem
EAPTLS_PrivateKeyFile /etc/radiator/certs/radiatordev.key
#EAPTLS_PrivateKeyPassword whatever
AutoMPPEKeys
PostAuthHook file:"goodies/eap_acct_username.pl"
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPTypeTTLS
#EAPTLS_CAFile /etc/radiator/certs/demoCA/cacert.pem
EAPTLS_CAFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_interm.cer
#EAPTLS_CertificateFile /etc/radiator/certs/cert-srv.pem
EAPTLS_CertificateFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_cert.cer
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/cert-srv.pem
EAPTLS_PrivateKeyFile /etc/radiator/certs/radiatordev.key
#EAPTLS_PrivateKeyPassword whatever
PostAuthHook file:"goodies/eap_acct_username.pl"
AuthByPolicy ContinueWhileAccept
# Make sure MAC address is not blacklisted..
NoEAP
# Calling-Station-Id attribute is the user's MAC in this case.
AuthenticateAttribute Calling-Station-Id
AcceptIfMissing
Filename /etc/radiator/MacAddrBlacklist.txt
# Make sure USERNAME is not blacklisted..
NoEAP
AcceptIfMissing
Filename /etc/radiator/UsernameBlacklist.txt
NtlmAuthProg/usr/bin/ntlm_auth
--helper-protocol=ntlm-server-1 --require-membership-of="AD+Domain Users"
Domain AD
EAPTypePEAP, TTLS
#EAPTLS_CAFile /etc/radiator/certs/demoCA/cacert.pem
EAPTLS_CAFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_interm.cer
#EAPTLS_CertificateFile /etc/radiator/certs/cert-srv.pem
EAPTLS_CertificateFile
/etc/radiator/certs/radiatordev_education_ucsb_edu_cert.cer
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/certs/cert-srv.pem
EAPTLS_PrivateKeyFile /etc/radiator/
[RADIATOR] Define a global array
Hi there,
I am trying to setup a system that, on startup reads a DB table into a
hashed array and then makes this available to the rest of the hooks. A
later hook then takes this hashed array and parses it to add a value to
a custom attribute which is then used for later processing within a handler.
While I understand that globals are bad and should never be used, I
believe that making a DB request on every radius packet would have more
of an impact on performance for something that rarely changes (maybe
once a week or so) and so the positives outweigh the negatives.
What I had which doesn't seem to work was something along these lines.
# Hooks
StartupHook file:"%D/hooks/StartupHook-SetupGlobals.pl"
.
.
Secret blah
PreHandlerHook file:"$D/hooks/AddAttribute.pl"
.
Do Stuff
in the SetupGlobals file I have something like;
# Define a global (obviously, there is where I'd read in the DB table)
our %global_steve = (
'message1' => 'Steve was here',
'message2' => 'woot'
);
and then, when trying to reference it I have in the PreHandler hook
sub {
&main::log($main::LOG_INFO, "Test: $main::global_steve{'messsage1'}");
}
Which ends up printing out a blank.
Does anyone know of either, a way to get this going, or a way to read in
a db table of data and cache it for use in later hooks without having
each radius request generate another database call?
Thanks in advance,
--
Steve.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Define a global array
Hello Steve -
What you describe makes perfect sense - and this is exactly what globals are
for.
See the hooks in “goodies/hooks.txt” for lots of examples.
regards
Hugh
On 2 Apr 2014, at 10:59, Steve Phillips wrote:
> Hi there,
>
> I am trying to setup a system that, on startup reads a DB table into a
> hashed array and then makes this available to the rest of the hooks. A
> later hook then takes this hashed array and parses it to add a value to
> a custom attribute which is then used for later processing within a handler.
>
> While I understand that globals are bad and should never be used, I
> believe that making a DB request on every radius packet would have more
> of an impact on performance for something that rarely changes (maybe
> once a week or so) and so the positives outweigh the negatives.
>
> What I had which doesn't seem to work was something along these lines.
>
>
>
> # Hooks
> StartupHook file:"%D/hooks/StartupHook-SetupGlobals.pl"
>
> .
> .
>
> Secret blah
> PreHandlerHook file:"$D/hooks/AddAttribute.pl"
>
>
>
> .
> Do Stuff
>
>
> in the SetupGlobals file I have something like;
>
> # Define a global (obviously, there is where I'd read in the DB table)
> our %global_steve = (
> 'message1' => 'Steve was here',
> 'message2' => 'woot'
> );
>
> and then, when trying to reference it I have in the PreHandler hook
>
> sub {
> &main::log($main::LOG_INFO, "Test: $main::global_steve{'messsage1'}");
> }
>
> Which ends up printing out a blank.
>
> Does anyone know of either, a way to get this going, or a way to read in
> a db table of data and cache it for use in later hooks without having
> each radius request generate another database call?
>
> Thanks in advance,
>
> --
> Steve.
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Define a global array
Hey Hugh,
Yep, had a look through there but can't see how you'd use this to set an
array variable, or would &main::setVariable allow you to set a complex
variable (a hashed array for example) as opposed to a simple singular
variable?
I've sort of got this working to set a value based on what was listed in
the hooks.txt and fudging something together using a loop, the keys
directive and setting a prefix to the key so I end up with
&main::setVariable(global_steve.message1,"value")
&main::setVariable(global_steve.message2,"value2")
And then referencing it with
my $string = "Test: " . &main::getVariable('global_steve.'.$myMessage);
(which doesn't work :-( )
(I'm trying to do &main::log($main::LOG_INFO,
&main::getVariable($blerg)); where $blerg is defined as;
my $blerg = "global_steve.$someAttribute";
and $someAttribute is either message1 or message2
)
I'm also picking that &main::setVariable(global_steve{message1}) isn't
going to work either, but I guess I'll try that next.
Is there any way at all to get a hashed array available globally?
Of interest, when I set the variable in the first hook as follows
foreach my $key (keys %columns) {
&main::log($main::LOG_DEBUG,"setVariable $varName.$key =
$columns{$key}");
&main::setVariable($varName.$key, $columns{$key});
&main::log($main::LOG_DEBUG,&main::setVariable($varName.$key,
$columns{$key}));
}
It seems to print out to the logs the expected values, but when I use
the exact same &main::log line in the PreHandler hook it doesn't, it's
almost as if it's forgotten the variable set in the previous startup hook?
--
Steve.
On 2/04/2014 11:24 am, Hugh Irvine wrote:
>
> Hello Steve -
>
> What you describe makes perfect sense - and this is exactly what globals are
> for.
>
> See the hooks in “goodies/hooks.txt” for lots of examples.
>
> regards
>
> Hugh
>
>
> On 2 Apr 2014, at 10:59, Steve Phillips wrote:
>
>> Hi there,
>>
>> I am trying to setup a system that, on startup reads a DB table into a
>> hashed array and then makes this available to the rest of the hooks. A
>> later hook then takes this hashed array and parses it to add a value to
>> a custom attribute which is then used for later processing within a handler.
>>
>> While I understand that globals are bad and should never be used, I
>> believe that making a DB request on every radius packet would have more
>> of an impact on performance for something that rarely changes (maybe
>> once a week or so) and so the positives outweigh the negatives.
>>
>> What I had which doesn't seem to work was something along these lines.
>>
>>
>>
>> # Hooks
>> StartupHook file:"%D/hooks/StartupHook-SetupGlobals.pl"
>>
>> .
>> .
>>
>>Secret blah
>>PreHandlerHook file:"$D/hooks/AddAttribute.pl"
>>
>>
>>
>> .
>> Do Stuff
>>
>>
>> in the SetupGlobals file I have something like;
>>
>> # Define a global (obviously, there is where I'd read in the DB table)
>> our %global_steve = (
>>'message1' => 'Steve was here',
>>'message2' => 'woot'
>> );
>>
>> and then, when trying to reference it I have in the PreHandler hook
>>
>> sub {
>>&main::log($main::LOG_INFO, "Test: $main::global_steve{'messsage1'}");
>> }
>>
>> Which ends up printing out a blank.
>>
>> Does anyone know of either, a way to get this going, or a way to read in
>> a db table of data and cache it for use in later hooks without having
>> each radius request generate another database call?
>>
>> Thanks in advance,
>>
>> --
>> Steve.
>>
>>
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
> --
>
> Hugh Irvine
> h...@open.com.au
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc.
> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Define a global array
Actually, flag that - I found why it wasn't working and it was me
failing at perl.
&main::setVariable($varName.$key, $columns{$key});
should have been
&main::setVariable($varName . "." . $key, $columns{$key});
--
Steve.
On 2/04/2014 11:56 am, Steve Phillips wrote:
> Hey Hugh,
>
> Yep, had a look through there but can't see how you'd use this to set an
> array variable, or would &main::setVariable allow you to set a complex
> variable (a hashed array for example) as opposed to a simple singular
> variable?
>
> I've sort of got this working to set a value based on what was listed in
> the hooks.txt and fudging something together using a loop, the keys
> directive and setting a prefix to the key so I end up with
>
> &main::setVariable(global_steve.message1,"value")
> &main::setVariable(global_steve.message2,"value2")
>
> And then referencing it with
>
> my $string = "Test: " . &main::getVariable('global_steve.'.$myMessage);
>
> (which doesn't work :-( )
>
> (I'm trying to do &main::log($main::LOG_INFO,
> &main::getVariable($blerg)); where $blerg is defined as;
>
> my $blerg = "global_steve.$someAttribute";
>
> and $someAttribute is either message1 or message2
>
> )
>
> I'm also picking that &main::setVariable(global_steve{message1}) isn't
> going to work either, but I guess I'll try that next.
>
> Is there any way at all to get a hashed array available globally?
>
> Of interest, when I set the variable in the first hook as follows
>
> foreach my $key (keys %columns) {
>
> &main::log($main::LOG_DEBUG,"setVariable $varName.$key =
> $columns{$key}");
> &main::setVariable($varName.$key, $columns{$key});
> &main::log($main::LOG_DEBUG,&main::setVariable($varName.$key,
> $columns{$key}));
>
> }
>
> It seems to print out to the logs the expected values, but when I use
> the exact same &main::log line in the PreHandler hook it doesn't, it's
> almost as if it's forgotten the variable set in the previous startup hook?
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Some information lost during Diameter to Radius conversion
On 04/01/2014 09:52 PM, Arthur wrote: > File diameter_attrs.dat has for those AVP's: Thanks. If you can pass me diamter_attrs.dat and the tcpdump file, I can check what happens. If this is a bug, we'd be very interested to fix it. > Any ideas? May be you need a complete tcpdump for analysing? Yes, that would be very useful to see the details in the request. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
