Accounting-Response packet with invalid signature!
Hello, I am getting Accounting-Response packets from one particular NAS with an invalid signature. I verified the shared secret is correct. Radiusd is configured to proxy Accounting-Request packets the following way. proxy server { synchronous = no retry_delay = 10 retry_count = 30 dead_time = 300 } This particular NAS take about 25 seconds to send the Accounting-Response. By the time it's sent its response freeradius has moved on to the second or third retry. The authenticator calculated by the NAS is for the initial accounting packet and is invalid for the second request due to a change in the Acct-Delay-Time (and possibly proxy-state). Freeradius then bails out: Received Accounting-Response packet from with invalid signature! Server rejecting request 1. Finished request 1 Going to the next request rl_next: returning NULL Cleaning up request 1 ID 11 with timestamp 44206de3 If I change the config to: retry_delay = 30 retry_count = 1 then freeradius sleeps for 30 seconds and does not send a second packet. Waking up in 31 seconds... rad_recv: Accounting-Response packet from host :1813, id=1, length=25 Proxy-State = 0x323233 Sending Accounting-Response of id 223 to :51818 Finished request 0 What is the correct way to do this according to the RFC? 25 seconds is an extremely long delay but it seems there should be a way to handle this. I tried playing with cleanup_delay, but I'm not getting anywhere. Do I have to set the retry_delay very high to have a better chance? 25 seconds is a long time to wait if the host is actually down. Thanks, Ryan
"Ryan Melendez" <rmelendez@wayport.net> wrote:
This particular NAS take about 25 seconds to send the Accounting-Response. By the time it's sent its response freeradius has moved on to the second or third retry. The authenticator calculated by the NAS is for the initial accounting packet and is invalid for the second request due to a change in the Acct-Delay-Time (and possibly proxy-state). Freeradius then bails out:
The solution is to *not* have FreeRADIUS do re-transmits of accounting packets. If the other server doesn't respond, the accounting packet should be discarded. The NAS will take care of retries.
What is the correct way to do this according to the RFC? 25 seconds is an extremely long delay but it seems there should be a way to handle this. I tried playing with cleanup_delay, but I'm not getting anywhere. Do I have to set the retry_delay very high to have a better chance? 25 seconds is a long time to wait if the host is actually down.
Delete the code in the server that does the re-transmit of accounting packets. Alan DeKok.
participants (2)
-
Alan DeKok -
Ryan Melendez