Again: Major impact on authentication!

[Guilherme Franco]

Hello Mr. Nixon!

No, the radius server and the DB server are connected in the same
switch, using gigabit UTP, resulting in 0.090ms RTT.

The proxy server is also directly connected to this switch.

I've been using CVS builds mainly because the rlm_sqlippool was under
development with constant updates done by you. The last one I've used
was freeradius-server-snapshot-20070120.tar.bz2 but the same behaviour
appeared, then I've switched to 1.1.4.

Humm Oracle support would be great! But I remember that in the
previous builds, I had to remove the BEGIN from allocate-begin in
rlm_sqlippool.c and recompile it because Oracle understands BEGIN as a
function/procedure/transaction start and the next steps taken by
rlm_sqlippool didn't fit in the correct structure (missing END; and
other statements). That way, no errors raised but sqlippool wouldn't
recognize the IP queried by the SELECT then.

Mr. Peter, also importantly, as we have both static and dynamic
ippools, two instances of sqlippool was running, namely sqlippool
DYNAMIC and sqlippool STATIC, called in this order by radiusd.

The allocate-find was not working correctly, not giving the same
static IPs to the user every time, so I've decided to remove one
sqlippool instance and I've created the following function:


CREATE OR REPLACE FUNCTION FOOBAR(user text, pool text, nas text)
RETURNS inet AS $$
declare
ip_temp inet := null;
BEGIN
    if pool = 'DYNAMIC' then
select framedipaddress into ip_temp from radippool where expiry_time <
'now'::timestamp(0) and pool_name = pool ORDER BY (username <> user),
(callingstationid <> nas), expiry_time LIMIT 1 FOR UPDATE;
return ip_temp;
    end if;

    if pool <> 'DYNAMIC' then
     select framedipaddress into ip_temp from radippool where username
= user and pool_name = pool;

     if ip_temp is not null then
     return ip_temp;
        end if;

        if ip_temp is null then
select framedipaddress into ip_temp from radippool where expiry_time <
'now'::timestamp(0) and username = '' and pool_name = pool LIMIT 1 FOR
UPDATE;
UPDATE radippool SET username = user where framedipaddress = ip_temp;
return ip_temp;
        end if;

    END IF;

END;
$$ LANGUAGE plpgsql;

That way, allocate-find became just allocate-find = "select
FOOBAR('%{User-Name}','%{check:Pool-Name}','%{Calling-Station-Id}')"

No fail-over would occur anymore, the function works in less than
50ms, the static ip of the user is permanently written in the DB so I
think it became better this way, at least for me.

This setup was running fine since October 2006, until now that things
started to freak out.

Thank you!


On 2/6/07, Peter Nixon <listuser at peternixon.net> wrote:
> On Tue 06 Feb 2007 15:27, Alan DeKok wrote:
> > Guilherme Franco wrote:
> > > Also, it's important to note that this server is the proxy radius and
> > > those error messages appear:
> > >
> > > Error: Discarding duplicate request from client ERX-1:50000 - ID: 115
> > > due to unfinished request 32
> > >
> > > Info: The maximum number of threads (32) are active, cannot spawn new
> > > thread to handle request
> > >
> > > Error: WARNING: Unresponsive child (id 1315006816) for request 105
>
> Do you by any chance have a "statefull" firewall between your radius server
> and database?
>
> >   All of those messages are caused by the same problem: something is
> > preventing the server from working.  Find out what it is, and fix the
> > problem.
> >
> > > Error: Internal error processing module entry
> >
> >   It might have helped if you posted that message earlier.  Internal
> > errors ALWAYS indicate something bad happening.
> >
> >   In this case, you're running 1.1.x, and somehow the data structures in
> > the server have gotten corrupted.  That's a VERY likely reason why the
> > server is broken.
> >
> >   As yo how to see what's going wrong, run the server under valgrind.
>
> There _may_ be a problem with rlm_sqlippool in 1.1.4 (it is marked as an
> unstable module in 1.1.4)
> If at all possible please consider updating to CVS head as there has been
> allot of work on sqlippool and the postgresql driver. In-fact the latest
> version of sqlippool _should_ work on Oracle (which I remember you wanted to
> do previously) although I have not tested this functionality. (rlm_sqlippool
> in 1.1.4 relies on a bug in rlm_sql_postgresql to work, hence the reason it
> doesn't work properly with other DBs)
>
> Alternatively you could backport the cvs head version of sqlippool to 1.1.4
> which is something I have been considering for the 1.1.5 release but have
> yet to find the time to do (but would happily accept donations to do so :-)
>
>
> --
>
> Peter Nixon
> http://www.peternixon.net/
> PGP Key: http://www.peternixon.net/public.asc
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>