On May 3, 2025, at 6:09 PM, Ibrahemoo Ghost <ibrahemooghost@gmail.com> wrote:
Ok so now you pointed me in the right direction, in my configuration I have an external script written in C lang to authenticate users using the exec module which is what takes a long time to execute and causes the problem.
Yes, that would be it. Exec'ing a script is very, very, slow. The server also comes with Perl and Python plugins. Switching to those will be significantly faster than running a script. But the short answer is "don't do that". The server has enough functionality that external scripts are pretty much never needed. And after 25+ years, the only time I've seen Perl / Python being needed is when there's a third-party API which is only available via a Perl / Python library. I have confidence that most scripts can be re-written in "unlang" statements. Perhaps you could explain what the script does?
But the module is important to my setup, my question is how can I solve the accounting packet drop internally, is modifying the pool values make any difference?
No. The issue is that the server is spending all of its time waiting for the script to return. There are a few possible solutions here which could help: 1) convert the script to "unlang" policies. This is almost always possible 2) or, run two copies of FreeRADIUS. One for authentication, and one for accounting. That way if the authentication server is slow, it doesn't affect the accounting server. 3) convert your configuration to the git "master" branch which will become v4. :) If you're not using RADIUS/TLS, it should be reasonably straightforward. The entire threading model of v4 has been redesigned. In v3, the server needs to block while it's waiting for a script to return. In v4, the server doesn't need to block. This means that it can continue running, and process Accounting-Request packets, while it's waiting for an authentication script to return. But the best solution is "don't run a script for every packet". Alan DeKok.