[RADIATOR] Unknown reply received in AuthRADIUS

Hugh Irvine hugh at open.com.au
Thu May 2 02:18:40 CDT 2013


Hello Jim -

You need it in *both* AuthBy RADIUS clauses.

regards

Hugh


On 2 May 2013, at 15:56, Jim Tyrrell <jim at scusting.com> 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 <jim at 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 at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> --
>> 
>> Hugh Irvine
>> hugh at 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.
>> 
> 


--

Hugh Irvine
hugh at 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.



More information about the radiator mailing list