On Thu, 22 Nov 2012, alan buxey wrote:
> > If it is common knowledge to eduroam operators, then you can laugh at
> > me for not paying attention, or checking this log often or carefully
> > enough!
>
> its there in the default dictionary (this is from 4.10)
Ah that'll be why then. I'm a bit o
Hi,
> If it is common knowledge to eduroam operators, then you can laugh at me
> for not paying attention, or checking this log often or carefully enough!
its there in the default dictionary (this is from 4.10)
# TERENA VSA's
#
VENDOR TERENA 25178
VENDORATTR 25178 eduroam-SP-Country 1
Don't know if this is common knowledge, but I only just noticed it:
Thu Nov 22 22:38:13 2012: ERR: Attribute number 10 (vendor 25178) is not
defined in your dictionary
Turns out that this is TERENA, for which in my dictionary I now have:
## TERENA
VENDOR Terena 25178
VENDORATTR 2
Hello Ricardo -
In my consulting practice I almost always find that splitting the configuration
up into multiple separate Radiator instances is the preferred approach.
I generally end up with a single RADIUS "frontend" authentication process (and
a single TACACS "frontend" process if required)
Hello Jim -
I suggest you run your configuration from the command line so you can see any
Perl error messages.
Ie. cd /your/Radiator/directory; perl radiusd -foreground -log_stdout -trace 4
-config_file /your/Radiator/configuration/file
regards
Hugh
On 23 Nov 2012, at 02:51, Jim Tyrrell
Hello Heikki.
Just now we have another delay issue, and we have checked that the delay
is in the queue. The numbers of Recv-Q queue are as follows :
Time -- Recv-Q
12:31:30 -- 47928
12:31:32 -- 48752
12:31:34 -- 47608
12:31:36 -- 64528
12:31:38 -- 61984
12:31:40 -- 55360
12:31:42 -- 51616
Hi,
I have TACACS currently working and authenticating against a local filem
but now I want to proxy authentication to another TACACS server if the
user is not defined locally. I have added an 'AuthBy TACACSPLUS' but I
am getting an the following error:
Thu Nov 22 15:47:05 2012: ERR: Could no
On 11/21/2012 04:00 PM, Ricardo Martinez wrote:
> So far, the DB seems not to be the problem, according to the
> statistics file in Radiator the answer from database is very quick,
> from 0.03 secs to 0.07 secs, but the request using the
> "simpleClient.pl" tool are taking near to 2 or 3 secs to b
