simultaneous checking

[Phil Mayers]

On Tue, Jul 21, 2009 at 11:30:31PM +0100, Ivan Kalik wrote:
>> HA!  I figured it out: the acctsessionid field was truncating the
>> Acct-Session-Id attribute being received from the NAS.  I bumped the
>> field up to 100 characters, and viola, the default SQL queries in
>> dialup.conf started working.  Yeah!
>>
>> We actually had the same problem with the callingstationid field.
>>
>> I'd recommend the radacct table have an increased field size for
>> acctsessionid and callingstationid.  I know it can be tweaked by the
>> user afterwards, but if it was larger to begin with, problems like the
>> ones I encountered wouldn't crop up.
>
>Why? Most companies have sane administartors who don't create such
>problems for themselves.

The implication that only insane people want to store long fields in a 
database is a pretty peculiar one...

At the very least if the database schema contains sized fields, they 
should be sized up to the length of a radius AVP i.e. 253 characters.  
The principle of least surprise and avoidance of premature optimisation 
seem to apply.

We've had the exact same problem here; perfectly legitimate NASes that 
send fields longer than the FreeRadius SQL schema definition uses. In 
the first case, it was NASes off-site sending accounting to our eduroam 
server. The 2nd was a newer model of wirelss AP. IIRC we've seen both 
longer Acct-Session-Id and NAS-Port-Id fields.

After the 2nd outage this caused (we rely on near realtime accounting) I 
looked into it, and found that postgresql suffers no performance benefit 
from using "varchar(n)" and I simply altered all the "varchar" fields to 
type "text". We have since experienced no such problems. So, at the very 
least I'd recommend changing the default postgresql accounting schema.

radcheck/radgroupcheck are obviously a different matter, and capping the 
length of those fields (which after all go into AVPs) makes sense. I 
would still recommend varchar(253) rather than some arbitrary shorter 
length though.