Hello Jim - You need it in *both* AuthBy RADIUS clauses.
regards Hugh On 2 May 2013, at 15:56, Jim Tyrrell <[email protected]> wrote: > I already have IgnoreAccountingResponse in my AuthBy RADIUS below, is that > the correct place for it? > > Jim. > > On 02/05/2013 00:38, Hugh Irvine wrote: >> 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 <[email protected]> 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 >>> [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. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
