Freeradius not sending traffic-shaping attributes randomly (Works when in debug mode)
modesto at hubsoft.com.br
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 hubsoft.com.br> wrote:
>> On 15/12/2021 17:59, Alan DeKok wrote:
>>> On Dec 15, 2021, at 3:31 PM, Antônio Modesto<modesto at hubsoft.com.br> 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?
>>> 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? Seehttp://www.freeradius.org/list/users.html
Att, *Antônio Modesto*
More information about the Freeradius-Users