Re: [RADIATOR] rapwtst and CoA-Request Error-Cause

Vangelis: Have you tried adding the -trace option to radpwtst? On Jul 29, 2010, at 12:48 PM, Vangelis Kyriakakis wrote: > Hello, > > We are using radpwtst to send CoA packets to a Cisco NAS. If there > is a problem the NAS sends back a CoA NAK packet which contains the > Error-Cause attr

[RADIATOR] Any recent benchmarks for Radiator?

Hi everyone In a near future, I'll be needing to implement a RADIUS forwarding solution for both Authentication and Accounting. My systems responsibility will only be, based on the typology of the request, to forward it to a given remote server, get the response and send it back to the originating

[RADIATOR] dictionary entries for Ascend conflict with IANA assigned ones

Dear all The standard radiator dictionary file specifies at least a pair of invalid entries sharing the same ID. Apparently, Ascend defines a set of attributes on the global  (IANA assigned) range. ATTRIBUTEX-Ascend-FCP-Parameter119string - conflicts with Digest-Domain ATTRIBU

[RADIATOR] PreClientHook not behaving as expected

This looks like a basic question, but I haven't been able to sort it out. Basically I have a structure of Radiator AuthBy and Handlers set for Accounting and needed to filter out some "special" packets being sent to the server. I've done this with a specific hook, pointed it to a ClientHook claus

Re: (RADIATOR) feature request

Hugh, about the per-handler debug level... how exactly is this feature accomplished? and how does PacketTrace work on 3.0? are these related? -B - Original Message - From: "Hugh Irvine" <[EMAIL PROTECTED]> To: "peter moody" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, March 1

(RADIATOR) AuthBySQL and PostAuthHook behaviour

Hi guys Here's something I've been worrying about for a while. As we were braintorming a while ago, some of us figured this could be a bug/feature instead of a programming issue. We managed to trim down the code to the following testing lines. Our doubt is if should be this the correct behaviour f

(RADIATOR) missing AcctColumnDef

hi there there's a hack described in the user's manual (6.28.13) which stores the timestamp of the start packet for a stop packet (with time()-acct_session_time). AcctColumnDef STARTTIME, %b-0%{Acct-Session-Time},literal What I'm trying to do is inserting the formatted date & time of the st

(RADIATOR) LDAP return code

Hi all We're starting to use radiator on a test environment where we're using some strange e-commerce vendor implementation of a database which uses the LDAP protocol for querying and returning data. I've been able to query all the data I want to, using the standard authby LDAP2 configuration, b

(RADIATOR) parsed variables on AuthBy configuration parameters

Hi everyone I have a AuthBy clause defined this way: Identifier primary Host%{GlobalVar:PrimaryServer} AuthDN %{GlobalVar:LDAPBindDN} AuthPassword%{GlobalVar:LDAPBindPW} Port389 BaseDN %{GlobalVar

Re: (RADIATOR) PAM auth

hey i'm still looking at this... last thing I done was to try to use /usr/lib/security/pam_sample.so.1 as the PAM library (a sample dummy PAM) with always_succeed as a flag. Now it does work so this might be a Solaris problem... - Original Message - > > hi there > > we've been trying to

(RADIATOR) LDAP connection re-usage

hi there. we've been using Radiator for quite a while as a proxy, twiddling configurations and getting strange conclusions about smoothly migrating from Sun Radius to Radiator. we're currently lookingfor the following behaviour: authentication packets : LDAP (AuthbyLDAP2.pm) [checking usernam

Re: (RADIATOR) ERR: Could not bind connection with ,,error: LDA P_INAPPROPRIATE_AUTH. Disconnecting

hello all i've been experiencing some problems too with perl-LDAP-0.20. I was able to connect to the LDAP server (bind as directory manager) and I couldn't get any attribute from LDAP (I mean it was waiting for some strings and all it got was some weird data (radiator debug interpreted it as ARRA

(RADIATOR) Conditional Hook Execution

hi we've been fiddling along with Hooks in order to do some customized authorization code on our dial-in accesses. the user is first authenticated by LDAP (so far so good) but the Hook code is always executed, even if the LDAP authentication failed. the config file is something like

(RADIATOR) perl global variables

hi all is there any way to define a "global" variable in a startup hook that can be used anywhere else (a pre or post-auth hook) in the code? I want to parse a file on startup (initialization/hangup) and to load some values related to pricing plans and access-control structures to hashes or array

(RADIATOR) kill -HUP causes AuthBy clauses Identifiers to be lost?

hi all is anyone aware of problems like AuthBy identifiers (passed from Radiators AuthBy clauses to custom code in hooks) being lost after a kill -HUP ? I'm now using radiator 2.18 and I almost swear this kind of feature was working a few weeks ago with a previous version of radiator, altough it

Re: (RADIATOR) kill -HUP causes AuthBy clauses Identifiers to be lost?

hello again > I don't have exactly the same setup here, so could you try something for me > please? In your code (shown below), I would like to know which line is > causing the problem: > >if ($code eq 'Access-Request') { > > my $authby=Radius::AuthGeneric::find ('ldap_auth_id'); > my

[RADIATOR] Some Starent Networks VSA

Hi everyone While dealing with some Starent Networks equipment, I found out a few missing VSA on the stock Radiator dictionary file. There are some VALUE entries that don't exist on the stock file as well. What would be the right way to have these values added to the supplied dictionary file? Can

[RADIATOR] radpwtst changes from v4.9 to v.14 (or Starent atributes?)

Hi everyone We've been running v4.9 on some of our production systems for quite a while now. The authentication instance is receiving packets from a Starent device forwarded to a Radiator instance on 4.9 and the authentication packet I get on my side looks something like this: Code: Access

Re: [RADIATOR] radpwtst changes from v4.9 to v.14 (or Starent atributes?)

ever since fixed the issue. The servers were migrated yesterday and everything is running smoothly. Best regards. Bruno Tiago Rodrigues On Mon, Feb 16, 2015 at 3:22 PM, Heikki Vatiainen wrote: > On 02/16/2015 04:55 PM, Heikki Vatiainen wrote: > > > I tried replicating the problem b