Hi Heikki,
Excerpts from Heikki Vatiainen's message of Fri May 10 15:55:22 +0200 2013:
> Since you have not specified FailureBackoffTime it defaults to 0 and
> might be the cause of the problem you see.
Even with a "FailureBackoffTime 300" the problem is reproducible. For now I'll
revert to using the default failure detection mechanism.
Here's logs of a packet stuck in re-transmit with
UseStatusServerForFailureDetect:
*** Sending to 127.0.0.1 port 1824 ....
Code: Accounting-Request
Identifier: 169
Authentic: <215><135><238><164><229><163>`r<8><29><12>E6c8<186>
Attributes:
User-Name = "a"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Identifier = "203.63.154.1"
NAS-Port = 1234
NAS-Port-Type = Async
Acct-Session-Id = "00001234"
Acct-Status-Type = Start
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
Acct-Delay-Time = 0
Timestamp = 1368196514
Proxy-State = OSC-Extended-Id=169
Fri May 10 16:43:39 2013: INFO: AuthRADIUS : No reply after 505 seconds and 3
retransmissions to 127.0.0.1:1824 for a (135)
and without UseStatusServerForFailureDetect:
Fri May 10 16:52:12 2013: WARNING: ProxyAlgorithm LOADBALANCE Could not find a
working host to proxy to
Fri May 10 16:52:12 2013: INFO: AuthRADIUS : Could not find a working host to
forward a (4) after 4 seconds. Ignoring
Fri May 10 16:52:12 2013: INFO: AuthRADIUS : No reply after 4 seconds and 3
retransmissions to 127.0.0.1:1824 for a (129). Now have 1 consecutive failures
over 0 seconds. Backing off for 300 seconds
--
todor
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
