Freeradius not sending traffic-shaping attributes randomly (Works when in debug mode)
terry.burton at gmail.com
Thu Dec 16 12:07:06 CET 2021
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?
> > 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:
More information about the Freeradius-Users