On Fri, Dec 03, 2010 at 12:20:04PM +0100, Alan DeKok wrote:
> Josip Rodin wrote:
> > Just ran across this IRL:
> >
> > Calling-Station-Id: GigabitEthernet 1/0/3.2045:2045#587202578###pppoe
> > c0:d0:44:e4:cf:3b#
>
> Arg. That's a *stupid* thing to do.
>
> It would have been saner to define VSAs to hold all of this
> information, or to re-use the standard attributes.
The RADIUS client is a Cisco NAS :)
> > But:
> >
> > Mon Nov 29 16:54:16 2010 : Error: [our_sql] Couldn't insert SQL accounting
> > START record - ERROR: value too long for type character varying(50)
> >
> > The situation is actually a bit inconsistent:
> >
> > raddb/sql/mssql/schema.sql: [CallingStationId] [varchar] (30) DEFAULT
> > ('') FOR [CallingStationId],
> > raddb/sql/mysql/schema.sql: callingstationid varchar(50) NOT NULL default
> > '',
> > raddb/sql/postgresql/schema.sql: CallingStationId VARCHAR(50),
> > raddb/sql/postgresql/schema.sql: CallingStationId VARCHAR(50),
> >
> > Is there really much point in limiting this?
> > The specification seems to say it's a string of an arbitrary length...
>
> No more than 253 octets. 99.999% of the time, smaller than 50.
Yes, well, at least synchronize MS SQL schema with that :)
> My $0.02 is that you can change the schema, but it would be better to
> fix the PPoE server. Have it send *useful* information, and not random
> concatenations of arbitrary text.
I already told PostgreSQL to just stop limiting it, because AFAICT there's
no actual benefit.
I told the people in charge for that Cisco box to compare its IOS to another
which doesn't do this on the same input data, instead it does things like
this:
"0026-5a86-982e eth 2/0/1:4096.2241 0/18/0/5:0.35"
--
2. That which causes joy or happiness.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
