Hello Jim -
Just add "IgnoreAccountingResponse" to your AuthBy RADIUS clauses.
See section 5.32.30 in the Radiator 4.11 reference manual ("doc/ref.pdf").
regards
Hugh
On 2 May 2013, at 04:49, Jim Tyrrell <j...@scusting.com> wrote:
> Hi,
>
> I have a default accounting handler which currently formats a few
> attributes via a hook, updates a MySQL database with session info, and
> then relays the RADIUS packet onto a couple of Cisco management servers
> (so they can maintain a mapping of user to IP).
>
> We have always had a few "Unknown reply received in AuthRADIUS", but
> quite rarely and then only a handful at a time so ignored them. I had
> assumed it was down to the remote RADIUS replying after Radiator had
> timed out the request (RetryTimeout 5) and so it was no longer valid -
> is that a correct assumption?
>
> However, I then added another AuthBy between the MySQL update and the
> RADIUS proxy to update a 2nd MySQL server (that will eventually replace
> the current MySQL), and now I get floods of "Unknown reply received in
> AuthRADIUS" approx 10 seconds after starting the RADUS process. I have
> 'Retries 2' so 10 seconds would be the time taken before giving up the
> AuthBy RADIUS.
>
> I dont understand why adding in an AuthBy before the AuthBy RADIUS could
> have an impact? Even if the new AuthBy is slow, and I dont believe it
> is as I have seen no timeouts for it, then wouldnt that just delay the
> RADIUS proxy sending rather than effect its performance? My accounting
> handler is as follows:
>
> <Handler>
> AuthByPolicy ContinueAlways
> AccountingHandled
> PreProcessingHook file:"%D/scripts/format_attributes.pl"
>
> ## Log User session status to MySQL servers via insert/update/delete
> statements
> AuthBy RadiusOnline-Start
> AuthBy RadiusOnline-Alive
> AuthBy RadiusOnline-Stop
>
> ## NEW AuthBy to log to new MySQL server via stored procedure
> AuthBy RadiusSessionUpdate
>
> ## Proxy accounting packet to Cisco management server 10.153.253.1
> AuthBy Proxy-to-CiscoSM
>
> ## Proxy accounting packet to Cisco management server 10.153.253.12
> AuthBy Proxy-to-CiscoSM_lab
>
> </Handler>
>
> The remote RADIUS servers are defined as such:
> <AuthBy RADIUS>
> Identifier Proxy-to-CiscoSM
> <Host 10.153.253.1>
> Secret mypassword
> RetryTimeout 5
> Retries 2
> </Host>
> IgnoreAccountingResponse
> NoDefault
> </AuthBy>
>
> The messages I get are:
> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
> for request 26 from 10.153.253.1:1646
> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
> for request 26 from 10.153.253.12:1646
> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
> for request 27 from 10.153.253.1:1646
> Wed May 1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
> for request 27 from 10.153.253.12:1646
> Wed May 1 19:18:54 2013: WARNING: Unknown reply received in AuthRADIUS
> for request 29 from 10.153.253.1:1646
>
> I thought about changing the order of the AuthBy's and tweaking the
> timeouts but want to try and understand how the additional AuthBy could
> of resulted in this issue before blindly try other things. I guess
> ideally I need to do trace 4 debugs and packet captures to verify delays
> in the remote RADIUS replying, but the server is very busy and its hard
> to piece the incoming and outgoing Radius packets together in all the noise.
>
> Thanks.
>
> Jim.
>
> _______________________________________________
> 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
