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 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... -- 2. That which causes joy or happiness.
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 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...
Pending on client, CallingStationId could be a mac address or an ip address or a string. So 50 char is a good thing that will cover all common case. If you are sure of the retrieved CallingStationId format you could discreased it to your needs in the sql table(ip address= 15 char, Mac address= 17 char).
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.
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. 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. Alan DeKok.
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.
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 modified the SQL schema locally to do that. It's also worth noting that 253 octets of radius value can expand to 3*253 if they're all "unsafe" characters and have to be =XX escaped; dumb behaviour or not, it's very unfortunate when a NAS brings your whole radius->SQL infrastructure crashing to a (silent) halt because of unnecessary field length restrictions ;o)
On Fri, Dec 03, 2010 at 12:12:52PM +0000, 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 char(N) over "text". The latter should IMHO always be used, and we modified the SQL schema locally to do that.
I should note that the same is for varchar (character varying) with no specified limit. IOW, alter table radacct alter column callingstationid type varchar; -- 2. That which causes joy or happiness.
Alan DeKok <aland@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 information, or to re-use the standard attributes.
I fail to see how that is wrong. It *is* the NASes Calling Station identificator. What do you suggest a PPPoE concentrator should use? Yes, I know RFC 2865 says "phone number". But if fails to say anything about the situation where there is no originating phone number. So vendors use what they have. And port/vlan/mac is the best they can do unless they have some PPPoE intermediate agent information. Bjørn
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". These attributes have names, specific meanings, and well-defined formats. I have no idea why many vendors are unable to use them.
Yes, I know RFC 2865 says "phone number". But if fails to say anything about the situation where there is no originating phone number. So vendors use what they have. And port/vlan/mac is the best they can do unless they have some PPPoE intermediate agent information.
So define VSAs. Other vendors have. It's not hard. Alan DeKok.
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.
Yes, I know RFC 2865 says "phone number". But if fails to say anything about the situation where there is no originating phone number. So vendors use what they have. And port/vlan/mac is the best they can do unless they have some PPPoE intermediate agent information.
So define VSAs. Other vendors have. It's not hard.
I agree with you that a random string is too vague, but in practice that's actually not bad, compared to the situation that I've had lately, where one set of PPPoE NASes was sending that information like this, another set of PPPoE NASes didn't send *anything*, another set of PPTP NASes sent Tunnel-* attributes, and yet another set of PPTP NASes decided to send nothing. They're all fairly similar Ciscos, but some have funky LAC's at the other end, some have a funky T train IOS, some have rabies... Getting a string full of actual information and worrying how to store it and parse it is a good kind of worry. -- 2. That which causes joy or happiness.
participants (5)
-
Alan DeKok -
Bjørn Mork -
Josip Rodin -
Phil Mayers -
yzy-oui-fi