Hello Traiano -

For your testing you should be using a separate configuration file using only 
the minimum you are trying to test.

You can do this either on a lab machine (preferable), or using different port 
numbers.

The idea being to use only the configuration file elements you are trying to 
test.

I generally start with "goodies/simple.cfg" on my laptop for first pass testing.

BTW - what version of Radiator are you running?

regards

Hugh


On 20 May 2012, at 21:54, Traiano Welcome wrote:

> Hi Hugh
> 
> I'm currently handling radius requests with the following clause:
> 
> ----
> #test clause for debugging bad authenticator errors
> <Client 41.181.89.29>
>        Secret r4nd0m1
>        IgnoreAcctSignature
>        <AuthBy SQL>
>                DBSource        dbi:Pg:dbname=dbrecords;host=localhost
>                DBUsername      xxxxxx
>                DBAuth           yyyyyyyy
>                AuthSelect
>                AccountingTable tablerecords
>                AcctColumnDef nasidentifier,NAS-Identifier
>                AcctColumnDef timestamp,Timestamp
>                SQLRecoveryFile /var/log/radius/acmemissedacctlog.%Y-%m-%d
>        </AuthBy>
> </Client>
> ---
> 
> But I'm still seeing the error message, and  no accounting responses to the 
> NAS/LB. The IgnoreAcctSignature doesn't  seem to have any effect.
> 
> (I'm also noticing another oddity here, when I don't explicitly use the 
> "Secret ...." statement in the Client clause, Radiator  authentication of the 
> client fails with "ERR: No Secret or TACACSPLUSKey defined for Client", even 
> though I can see from the debug that Radiator is successfully selecting the 
> secret from the postgresql database)
> 
> Is it possible this error is due to another auth failure other than a packet 
> signature check failure?
> 
> Let me know if there's any further information I can send through that might 
> shed more light on the issue!
> 
> Thanks,
> Traiano
> 
> PS.: I tried  the ignoreacctsignature paramater in the ClientListSQL clause, 
> changing the postgresql column data  type to "text" and setting it to a value 
> of 1, but it seems the parameter has no effect.  
> ________________________________________
> From: Hugh Irvine [[email protected]]
> Sent: Sunday, May 20, 2012 2:26 AM
> To: Traiano Welcome
> Cc: [email protected]
> Subject: Re: [RADIATOR] [ "WARNING: Bad authenticator in request from .." on 
> CentOS host]
> 
> Hello Traiano -
> 
> For testing purposes I would suggest using a Client clause in the 
> configuration file so you know exactly what is happening.
> 
> For your ClientListSQL I'm not sure about using boolean for the field - I 
> would suggest text instead.
> 
> regards
> 
> Hugh
> 
> 
> 
> On 19 May 2012, at 19:47, Traiano Welcome wrote:
> 
>> Hi Hugh
>> 
>> Thanks for your response!
>> 
>> I don't use the Client clause (I'm using the  Handler clause to match 
>> NAS-Identifiers), but I see one can use this in the ClientListSQL clause as 
>> I've done below:
>> 
>> ---
>> <ClientListSQL>
>>       DBSource        dbi:Pg:dbname=<hidden>;host=localhost
>>       DBUsername      <redacted>
>>       DBAuth          <obscured>
>>       GetClientQuery  select nas_ip,secret,ignoreacctsignature,dupinterval 
>> from naslist
>> </ClientListSQL>
>> ---
>> 
>> ... with a corresponding modification from my "naslist" table as follows:
>> 
>> ---
>>           Table "public.naslist"
>> 
>>      Column        |  Type   |  Modifiers
>> ---------------------+---------+--------------
>> nas_ip              | inet    | not null
>> secret              | text    | not null
>> ignoreacctsignature | boolean | default true
>> dupinterval         | integer | default 2
>> hostname            | text    |
>> description         | text    |
>> ---
>> 
>> Example:
>> 
>> --
>>    nas_ip     |  secret   | ignoreacctsignature | dupinterval
>> ----------------+-----------+---------------------+-------------
>> loa.dba.lan.cer   | <redacted>  | t                   |           2
>> --
>> 
>> 
>> However I'm still seeing the "WARNING: Bad authenticator in request from 
>> ..." messages after restarting radius several times. How can  I debug this 
>> further ?
>> 
>> I see the "IgnoreAcctSignature" is not supported in the Handler statement.
>> 
>> Traiano
>> 
>> 
>> 
>> ________________________________________
>> From: Hugh Irvine [[email protected]]
>> Sent: Saturday, May 19, 2012 6:45 AM
>> To: Traiano Welcome
>> Cc: [email protected]
>> Subject: Re: [RADIATOR] (no subject)
>> 
>> Hello Traiano -
>> 
>> You can try setting "IgnoreAcctSignature" in the client clause in the Centos 
>> Radiator configuration.
>> 
>> See section 5.7.3 in the Radiator 4.9 reference manual ("doc/ref.pdf").
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>> On 19 May 2012, at 10:15, Traiano Welcome wrote:
>> 
>>> Hi List
>>> 
>>> I have a a 'cluster' of 5 Radiator radius servers behind a FreeBSD server 
>>> running Radiator in load balancing configuration. The radius servers behind 
>>> the load balancer do authentication and accounting, 4 of them are freebsd 
>>> running in vmware  VMs and the fifth is a CentOS physical host. While I see 
>>> the FreeBSD radius auth/acct servers are handling requests correctly, 
>>> logging accounting to a postgresql database, I am seeing all the accounting 
>>> requests proxied via the load-balancer to the CentOS host fail with the 
>>> following error in the logs:
>>> 
>>> ---
>>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from 
>>> lo.ad.bal.ancer (na.s.100.20)
>>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from 
>>> lo.ad.bal.ancer (na.s.100.20)
>>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from 
>>> lo.ad.bal.ancer (na.s.0.100)
>>> Sat May 19 00:50:52 2012: WARNING: Bad authenticator in request from 
>>> lo.ad.bal.ancer (na.s.0.100)
>>> ---
>>> 
>>> No accounting packets are being logged to the postgresql database on the 
>>> CentOS host, as a consequence (?)
>>> 
>>> Normally I would expect this to be due to a mismatch in secrets between the 
>>> NAS (here being the Radiator load balancer?) and the auth'ing/accounting 
>>> radiator server, however the secret configured on  the freebsd server is 
>>> identical to that on the CentOS host and the radiator load balancer, and 
>>> the FreeBSD radius server is auth'ing and accounting successfully.
>>> 
>>> Running tcpdump on each system, I can see the following:
>>> 
>>> - The FreeBSD load-balancer is sending accounting requests to the CentOS 
>>> load balancer, but is seeing no responses in return
>>> - The CentOS auth/acct server is seeing requests from the load-balancer is 
>>> not sending accounting response packets back to the load balancer
>>> - The FreeBSD auth/acct server is happily receiving accounting requests and 
>>> sending responses from the load-balancer
>>> 
>>> So free flow of radius packets between the load-balancer and the CentOS 
>>> radiator server is unlikely to be the  issues ... After, all, no responses 
>>> are being sent out by the CentOS host in the first place.
>>> 
>>> The details of the load balancer and the two radius accounting/auth servers 
>>> behind it are as follows:
>>> 
>>> 1) FreeBSD Load Balancer server (Radiator Configured as a load balancer)
>>> 
>>> - FreeBSD 8.2-RELEASE-p6 #0
>>> - PERL (v5.12.4) built for amd64-freebsd
>>> - p5-Digest-MD5-2.51
>>> 
>>> 2) FreeBSD Radiator server handling RADIUS packets from the Load Balancer 
>>> (Radiator configured to auth from and account to a local postgresql 
>>> database)
>>> 
>>> - FreeBSD 8.2-RELEASE-p4 #2
>>> - PERL (v5.12.4) built for amd64-freebsd-thread-multi
>>> - postgres (PostgreSQL) 8.4.10
>>> - p5-Digest-MD5-2.51
>>> 
>>> 3) CentOS Radiator Server handling RADIUS packets from the Load Balancer 
>>> (Radiator configured to auth from and account to a local postgresql 
>>> database)
>>> 
>>> - CentOS release 6.2 (Final), 2.6.32-220.el6.x86_64 #1 SMP
>>> - v5.10.1 (*) built for x86_64-linux-thread-multi
>>> -  (PostgreSQL) 8.4.10
>>> - Digest::MD5  (2.51)
>>> - perl-Net-SSLeay-1.35-9.el6.x86_64
>>> - perl-Digest-HMAC-1.01-22.el6.noarch
>>> - perl-DBI-1.609-4.el6.x86_64
>>> - perl-DBD-Pg-2.15.1-3.el6.x86_64
>>> 
>>> Attached are the radiator configurations  for each of the above servers:
>>> 
>>> 1. My FreeBSD Load balancer's Radiator configuration:
>>> 2. The Radiator configuration on a working freebsd server:
>>> 3. The Radiator configuration on the CentOS server:
>>> 
>>> I've tried the following tests to confirm if this isn't a software/library 
>>> issue:
>>> 
>>> - reinstalled postgresql, Radiator and the associated PERL libraries a 
>>> number of times, testing different combinations of package versions - no 
>>> luck
>>> - tried CPAN perl libraries instead of the centos yum perl modules
>>> - installed radiator from source and using the rpm package
>>> - tried radiator 4.8 and 4.9
>>> - Postgresl 8.4 and 9.2 from source and rpm
>>> - Confirmed database connectivity between Radiator and Postgresql
>>> - Upping the radiator Trace level to 5 doesn't reveal any actual details of 
>>> possible cause of failure other than a dump of the radius 
>>> accounting-request packet (that I can recognise anyway :p)
>>> 
>>> I'd be grateful if someone could point out a likely cause of the CentOS 
>>> Radiator servers non-response to accounting-requests, or suggest some 
>>> additional detailed debugging techniques I could use?
>>> 
>>> Let me know if I should send some packet traces in addition to the above!
>>> 
>>> Many Thanks in advance!
>>> Traiano
>>> 
>>> 
>>> 
>>> <freebsd-auth-acct-host-radiusd.cfg><freebsd-load-balancer-radiator.cfg><centos-host-radiusd.cfg>_______________________________________________
>>> radiator mailing list
>>> [email protected]
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> 
>> --
>> 
>> Hugh Irvine
>> [email protected]
>> 
>> 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.
>> 
> 
> 
> --
> 
> Hugh Irvine
> [email protected]
> 
> 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.
> 


--

Hugh Irvine
[email protected]

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
[email protected]
http://www.open.com.au/mailman/listinfo/radiator

Reply via email to