too long Calling Station Ids

2010-12-03 Thread Josip Rodin
Hi, Just ran across this IRL: Calling-Station-Id: GigabitEthernet 1/0/3.2045:2045#587202578###pppoe c0:d0:44:e4:cf:3b# 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

Re: too long Calling Station Ids

2010-12-03 Thread yzy-oui-fi
Le vendredi 03 décembre 2010 à 11:52 +0100, Josip Rodin a écrit : Hi, Just ran across this IRL: Calling-Station-Id: GigabitEthernet 1/0/3.2045:2045#587202578###pppoe c0:d0:44:e4:cf:3b# But: Mon Nov 29 16:54:16 2010 : Error: [our_sql] Couldn't insert SQL accounting START

Re: too long Calling Station Ids

2010-12-03 Thread Alan DeKok
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

Re: too long Calling Station Ids

2010-12-03 Thread 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

Re: too long Calling Station Ids

2010-12-03 Thread Phil Mayers
On 03/12/10 11:51, Josip Rodin wrote: I already told PostgreSQL to just stop limiting it, because AFAICT there's no actual benefit. Under postgresql, there is NO performance benefit or storage space saving using varchar(N) or char(N) over text. The latter should IMHO always be used, and we

Re: too long Calling Station Ids

2010-12-03 Thread Alan DeKok
Phil Mayers wrote: Under postgresql, there is NO performance benefit or storage space saving using varchar(N) or char(N) over text. The latter should IMHO always be used, and we modified the SQL schema locally to do that. Patch ? Alan DeKok. - List info/subscribe/unsubscribe? See

Re: too long Calling Station Ids

2010-12-03 Thread Josip Rodin
On Fri, Dec 03, 2010 at 12:12:52PM +, Phil Mayers wrote: On 03/12/10 11:51, Josip Rodin wrote: I already told PostgreSQL to just stop limiting it, because AFAICT there's no actual benefit. Under postgresql, there is NO performance benefit or storage space saving using varchar(N) or

Re: too long Calling Station Ids

2010-12-03 Thread Bjørn Mork
Alan DeKok al...@deployingradius.com writes: 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

Re: too long Calling Station Ids

2010-12-03 Thread Alan DeKok
Bjørn Mork wrote: I fail to see how that is wrong. It *is* the NASes Calling Station identificator. What do you suggest a PPPoE concentrator should use? Something better. VSAs, even. Using random fields in random printable formats is a bad idea. RADIUS has the concept of attributes.

Re: too long Calling Station Ids

2010-12-03 Thread Josip Rodin
On Fri, Dec 03, 2010 at 09:41:07PM +0100, Alan DeKok wrote: Using random fields in random printable formats is a bad idea. RADIUS has the concept of attributes. These attributes have names, specific meanings, and well-defined formats. I have no idea why many vendors are unable to use them.