too long Calling Station Ids

[Josip Rodin]

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.