rlm_sqlippool

[Chris Knipe]

>> See below.  It can more than likely do with more indexes though.  I'm at
>> this stage obviously only experimenting...   I'm still checking, but I'm
>> *baffled* as to why the rlm_sqlippool won't reconnect to the database 
>> then!
>> As you said, it uses the SQL driver, whether it's PostGRE, mySQL, MSSQL,
>> Oracle, surely, the reconnections are handled in the sql driver itself 
>> and
>> not the module...   Alan, anything I can look at perhaps???
>
> I am not sure of the status of that. Reconnect may not be working at 
> present.
> We manage our database fairly carefully on a dedicated system so it 
> _never_
> goes down :-)

This, is weird.  I'll have to dig and test here.  I had a error in one of my 
queries (only saw it now after I posted my queries in the email).  It 
*seems* that if the DB Handle is down and it tries to execute a incorrect 
query when reconnecting, the driver stalls.  I fixed my error in my query, 
and am running at 12,800 successfull authentications using rlm_sqlippool, 
without a single problem.  The main thing with my test rig is that it's not 
busy.  Part of managing a database is killing idle connections :-)  That's 
why radius needs to reconnect the whole time...

I'm not sure now whether the above should be seen as a possible bug in 
rlm_sql, or in rlm_sqlippool, or whether it should be seen as a bug at all. 
IMHO however, the handles should reconnect and the radius server should not 
'stall' as such nevermind what happens.  It creates a major backlog of 
queries and no other requests can be processed untill the timeout occured 
(not tested in a threaded environment).

So far, it shows that IP addresses are also allocated correctly, as as it is 
supposed to by the queries, and specifically, the WHERE clauses....  So it 
seems all is well.  Provided enough attention is given and you have your 
thinking cap on, I'm pretty much happy to say that this works with mySQL as 
well then...
+-------------------+----------------------------+
| CallingStationID  | INET_NTOA(FramedIPAddress) |
+-------------------+----------------------------+
| 00:01:4A:5E:86:80 | 198.19.240.2               |
| 00:0F:EA:61:0F:B3 | 198.19.240.1               |
+-------------------+----------------------------+
2 rows in set (0.01 sec)


>> My structures below should be quick and easy to understand.  I'm sure
>> there's mistakes in it as well (which I hope will be pointed out to me),
>> and I hope other SQL servers will support INET_ATON() and INET_NTOA.
>> Perhaps add these as variables in FreeRadius (Alan?).  Considering pools
>> are moving to SQL as well now  -  which is VERY good IMHO, I think it's a
>> major waiste of space to allocate a VARCHAR(16) (at the minimum) to hold 
>> a
>> IP Address in a database, when we can do it as a integer...
>
> Actually, they ip_address file should be of type INET. I will make the 
> change
> this week after testing it.

Is that supported on all database platforms though?  As a 'default' 
configuration shipping with the FreeRadius distribution, I just feel that 
whatever is created / decided should be made generic enough so that it will 
work 'out of the box' so to speak..

Regards,
Chris.