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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
