Freeradius not sending traffic-shaping attributes randomly (Works when in debug mode)

Antônio Modesto modesto at
Thu Dec 16 12:35:15 CET 2021

On 16/12/2021 08:07, Terry Burton wrote:
> On Wed, 15 Dec 2021 at 21:22, Antônio Modesto<modesto at>  wrote:
>> On 15/12/2021 17:59, Alan DeKok wrote:
>>> On Dec 15, 2021, at 3:31 PM, Antônio Modesto<modesto at>  wrote:
>>>> I am facing a strange problem with one radius server (FreeBSD 12.2 + FreeRADIUS 2.0.21).
>>>     Which is end of life, dead, and not supported.
>>>> In a random way, Freeradius is not sending some traffic-shaping attributes in the Access-Accept to the NAS (I confirmed it with wireshark). What is puzzling me is that when I run radiusd in debug mode (-X), the problem disappears.
>>>     Where do these attributes come from?  You've been careful to not give any information about your configuration.
>>>     The server doesn't magically decide to behave differently from day to day.  In 99.999% of these situations, the database is overloaded.  So FreeRADIUS can't get the data it needs, and then things break.
>>>     If the server just uses flat-text files (and no database), then it will *never* suddenly start behaving differently.  It will *always* give exactly the same output for the same input.
>>>> I tried using raddebug but it uses a lot of CPU power, so it is not viable to run it in production. What do you guys suggest?
>>>     Upgrade.
>>>     And investigate database issues.  Check the radius.log file.  Odds are that there will be LOTS of complaints about "unresponsive child" or "module SQL is blocked".  Fix that.
>> I am sorry, I am using Freeradius 3.0.21, not 2.0.21.
>> But regarding the attributes, they are being read from the database
>> (PostgreSQL). What you said about database issues does not make sense to
>> me. If freeradius can't read something from the database, it should halt
>> the request, not respond a Access-Accept with truncated attributes. As I
>> said before, the weird part is that running freeradius in debug-mode
>> (single-threaded) the problem didn't happen.
> If the missing attributes are derived from group lookups then it is
> likely fixed by this:

That's exactly the case. The attributes are attached to a group, not 
directly to the user. I will try to upgrade and see what happens.

> -
> List info/subscribe/unsubscribe? See
Att, *Antônio Modesto*

More information about the Freeradius-Users mailing list