conflicting packet error
Hi, I sometimes see the following errors in FreeRadius logs: Received conflicting packet from client nas_test port 15089 - ID: 75 due to unfinished request. Giving up on old request. In this mailing list I read some comments about it and found out it is caused by slow database which is not able to handle requests on time. I enabled logging slow queries and noticed there are no queries taking more than 2 seconds. so what is exactly causing it? does adjusting nas timeout/retry or FreeRadius settings fix it? Thanks Sam
On Mar 22, 2017, at 2:36 PM, Sami Jorl via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I sometimes see the following errors in FreeRadius logs: Received conflicting packet from client nas_test port 15089 - ID: 75 due to unfinished request. Giving up on old request.
In this mailing list I read some comments about it and found out it is caused by slow database which is not able to handle requests on time. I enabled logging slow queries and noticed there are no queries taking more than 2 seconds.
2 seconds is a VERY long time. The database should respond in a few milliseconds.
so what is exactly causing it?
The database is slow.
does adjusting nas timeout/retry or FreeRadius settings fix it?
Fix your database. Alan DeKok.
2 seconds is a VERY long time. The database should respond in a few milliseconds.
most queries take less than 0.5 second and only a few take between 1-2 seconds.
The database is slow.
why should error occur on requests taking even 2 seconds? what is the exact meaning of this error?
Your NAS keeps sending the same packet over and over again every 2 seconds until it gets a response (or gives up completely). Freeradius can't reply unless the db responds in time, so when it receives the same packet again it complains and logs an error message. If 2 seconds is not enough for your db you might try to increase the retry interval on the NAS (but this way you're rather masking the problem and not fixing it). kind regards Pshem On Thu, 23 Mar 2017 at 09:44 Sami Jorl via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
2 seconds is a VERY long time. The database should respond in a few milliseconds.
most queries take less than 0.5 second and only a few take between 1-2 seconds.
The database is slow.
why should error occur on requests taking even 2 seconds? what is the exact meaning of this error? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Your NAS keeps sending the same packet over and over again every 2 seconds until it gets a response (or gives up completely). Freeradius can't reply unless the db responds in time, so when it receives the same packet again it complains and logs an error message. If 2 seconds is not enough for your db you might try to increase the retry interval on the NAS (but this way you're rather masking the problem and not fixing it).
Thanks for the explanation. Is is possible to know if these errors are for authentication requests or accounting requests? Does FreeRadius ignore one of the requests and answer the other one?
Hi,
2 seconds is a VERY long time. The database should respond in a few milliseconds.
most queries take less than 0.5 second and only a few take between 1-2 seconds.
ummm, even those values are too large. what sort of authentication are you doing here as many are quite timebound and the NAS will resend if it doesnt get a response within its timeout window alan
On Mar 22, 2017, at 4:42 PM, Sami Jorl via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
2 seconds is a VERY long time. The database should respond in a few milliseconds.
most queries take less than 0.5 second and only a few take between 1-2 seconds.
Perhaps you missed may comment where I said "The database should respond in a few milliseconds." If the doesn't respond quickly, it's broken.
The database is slow.
why should error occur on requests taking even 2 seconds?
Because it's slow?
what is the exact meaning of this error?
It means that the database is slow. This isn't rocket science. I suggest you fix the database instead of asking the same question over and over again. The answers we give won't change. Alan DeKok,.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Pshem Kowalczyk -
Sami Jorl