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.