Andrew Long wrote:
rlm_sql: Failed to create the pair: Unknown value Administrative for attribute Service-Type rlm_sql (sql): Error getting data from database
I am trying to get a second server (ver. 1.1.0) running mostly on the configs from an older (0.9.3). The sql tables are identical (except for some ip changes) and the radiusd.conf, sql.conf, etc are identical except for small details particular to system (I hope).
The problem you're running into is likely that the dictionaries have changed. Some of the older dictionaries were, quite frankly, wrong.
You'll have to update your configuration to use the new names for the attributes & values. Compare th 0.9.3 dictionaries to the new ones to see what the values mean...
Alan DeKok. --
Thanks Alan. (Sorry for the reply that went to you alone). How do you recommend I proceed when the A-V pair in question (Service-Type:Administrative-user) no longer exists in 1.1.0? The 1.1.0 dictionary only defines about 5 internal service types... VALUE Service-Type Voice 12 VALUE Service-Type Fax 13 VALUE Service-Type Modem-Relay 14 VALUE Service-Type IAPP-Register 15 VALUE Service-Type IAPP-AP-Check 16 ...whereas 0.9.3 defined many more (about 17, including Administrative-user). Would it be possible to simply use the old dictionaries (/usr/local/share/freeradius/*) on 1.1.0 as an interim solution until we have the new server built. We are trying to get this up asap. Not an elegent solution, but would it work? Or, do I need to dig deeper into some of those dictionary files to find a suitable A-V pair? Andrew
Long wrote:
How do you recommend I proceed when the A-V pair in question (Service-Type:Administrative-user) no longer exists in 1.1.0? The 1.1.0 dictionary only defines about 5 internal service types...
Did you look for it in ALL of the dictionaries? The 1.1.x version re-arranged the dictionary files to make more sense. Check that. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Long wrote:
How do you recommend I proceed when the A-V pair in question (Service-Type:Administrative-user) no longer exists in 1.1.0? The 1.1.0 dictionary only defines about 5 internal service types...
Did you look for it in ALL of the dictionaries? The 1.1.x version re-arranged the dictionary files to make more sense. Check that.
Alan DeKok.
"Unknown value Administrative for attribute Service-Type" (1.1.0) NOW... I found that 1.1.0 defines A-V pair Service-Type:Administrative-User in dictionary.rfc2865: VALUE Service-Type Administrative-User 6 Am I correct in thinking that an update to the tables (replacing "Administrative" with "Administrative-User") ought to fix this? Andrew
On Thursday 04 January 2007 09:09, Andrew Long wrote:
"Unknown value Administrative for attribute Service-Type" (1.1.0)
NOW...
I found that 1.1.0 defines A-V pair Service-Type:Administrative-User in dictionary.rfc2865:
VALUE Service-Type Administrative-User 6
Am I correct in thinking that an update to the tables (replacing "Administrative" with "Administrative-User") ought to fix this?
Andrew
In the 0.9.3 dictionaries, you should see the same number value associated with the Administrative Service-Type. Replacing it in your tables should work. Do you plan to use the latest version of FreeRADIUS (1.1.3) after resolving these issues? Kevin Bonner
Can you clarify: In 0.9.3 (/usr/local/raddb/dictionary): VALUE Service-Type Administrative-User 6 In 1.1.0 (usr/local/share/freeradius/dictionary.rfc2865): VALUE Service-Type Administrative-User 6 And this represents data from tables on BOTH servers: mysql> SELECT * from radgroupcheck where value like '%Administ%'; +----+-----------+--------------+----+----------------+ | id | GroupName | Attribute | op | Value | +----+-----------+--------------+----+----------------+ | 1 | colubris | Service-Type | == | Administrative | | 6 | nomadix | Service-Type | == | Administrative | +----+-----------+--------------+----+----------------+ 2 rows in set (0.00 sec) Now, 0.9.3 runs smoothly and returns no error... While 1.1.0 returns: rad_recv: Access-Request packet from host 204.95.127.xxx:2048, id=187, length=192 Acct-Session-Id = "538beb43" NAS-Port = 0 NAS-Port-Type = Wireless-802.11 User-Name = "hawth_cn3000" Calling-Station-Id = "00-02-2D-A7-90-E3" Called-Station-Id = "00-03-52-00-2A-70" Framed-IP-Address = 10.1.64.1 CHAP-Password = 0xbbcfb2ff55c0f0631707a373efafcc4d80 CHAP-Challenge = 0xb3b35eed6c545478a382df419e830423 NAS-Identifier = "M003-00235" NAS-IP-Address = 204.95.127.xxx Framed-MTU = 1496 Connect-Info = "HTTPS" Service-Type = Administrative-User Message-Authenticator = 0x56f3a49ec1ef7b05bbe9f308140c404c Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' modcall[authorize]: module "preprocess" returns ok for request 0 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 rlm_realm: No '@' in User-Name = "hawth_cn3000", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 modcall[authorize]: module "files" returns notfound for request 0 modcall[authorize]: module "mschap" returns noop for request 0 radius_xlat: 'hawth_cn3000' rlm_sql (sql): sql_set_user escaped user --> 'hawth_cn3000' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'hawth_cn3000' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 4 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'hawth_cn3000' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' ! ERROR rlm_sql: Failed to create the pair: Unknown value Administrative for attribute Service-Type rlm_sql (sql): Error getting data from database (It authenticates, but only sends the first of several A-V pairs needed by the CN3200: "At least one required internal page was not retrieved - Keeping previous set of internal pages." ) I apologize if this is getting unclear, please bear with me, I need to get this going. MUCH thanks. Andrew
On Thursday 04 January 2007 13:39, Andrew Long wrote:
Can you clarify:
In 0.9.3 (/usr/local/raddb/dictionary): VALUE Service-Type Administrative-User 6
In 1.1.0 (usr/local/share/freeradius/dictionary.rfc2865): VALUE Service-Type Administrative-User 6 ... Now, 0.9.3 runs smoothly and returns no error... While 1.1.0 returns:
Since 0.9.3 worked, then you can grep for Administrative in the 0.9.3 dictionaries to see what integer value is assigned to it. If it is found, then look for the Service-Type entry with the same integer value in the 1.1.0 dictionaries and use that newer name. If the Administrative Service-Type is not found, then it was silently ignored in 0.9.3 and finally reports an error in 1.1.0. Switching it from Administrative to Administrative-User should be all you need to do to resolve your issue. Kevin Bonner
Andrew Long wrote:
Am I correct in thinking that an update to the tables (replacing "Administrative" with "Administrative-User") ought to fix this?
Yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Am I correct in thinking that an update to the tables (replacing "Administrative" with "Administrative-User") ought to fix this?
Yes.
Now I still get: Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' with the net effect that only one A-V pair is sent and the colubris is left without needed page links. Jan 4 15:27:17 info iprulesmgr Loading local configuration settings for custom pages, redirection url's, ... Jan 4 15:27:18 info iprulesmgr Colubris RADIUS attribute (name='session-page') not specified, default restored. Jan 4 15:27:18 info iprulesmgr Colubris RADIUS attribute (name='transport-page') not specified, default restored. Jan 4 15:27:18 info iprulesmgr Colubris RADIUS attribute (name='fail-page') not specified, default restored. Jan 4 15:27:18 info iprulesmgr Colubris RADIUS attribute (name='logo') not specified, default restored. Jan 4 15:27:18 info iprulesmgr Using external login page (url='http://65.160.170.7/hotspots/hawthorn/login.html?loginurl=%l'). Jan 4 15:27:18 warn iprulesmgr At least one required internal page was not retrieved - Keeping previous set of internal pages. BUT: mysql> select * from radreply where username like '%hawth%'; +-----+--------------+-----------------+----+----------------------------------------------------------------------------+------+ | id | UserName | Attribute | op | Value | note | +-----+--------------+-----------------+----+----------------------------------------------------------------------------+------+ | 2 | hawth_cn3000 | Colubris-AVPair | = | login-url=http://xx.xx.xx.xx/hotspots/hawthorn/login.html?loginurl=%l | NULL | | 3 | hawth_cn3000 | Colubris-AVPair | = | transport-page=http://xx.xx.xx.xx/hotspots/hawthorn/transport.html | NULL | | 4 | hawth_cn3000 | Colubris-AVPair | = | session-page=http://xx.xx.xx.xx/hotspots/hawthorn/session.html | NULL | | 5 | hawth_cn3000 | Colubris-AVPair | = | fail-page=http://xx.xx.xx.xx/hotspots/hawthorn/fail.html | NULL | | 6 | hawth_cn3000 | Colubris-AVPair | = | logo=http://xx.xx.xx.xx/hotspots/hawthorn/signonpic.jpg | NULL | | 7 | hawth_cn3000 | Colubris-AVPair | = | access-list=loginserver,ACCEPT,tcp,xx.xx.xx.xx,all | NULL | | 8 | hawth_cn3000 | Colubris-AVPair | = | use-access-list=loginserver | NULL | | 9 | hawth_cn3000 | Colubris-AVPair | = | welcome-url=http://xx.xx.xx.xx/hotspots/hawthorn/welcome/index.html | NULL | | 10 | hawth_cn3000 | Colubris-AVPair | = | default-user-smtp-redirect=smtp-relay.xxxxx.net | NULL | | 36 | hawth_cn3000 | Colubris-AVPair | = | white-list=all,server-url | NULL | ??? Andrew
Andrew Long wrote:
with the net effect that only one A-V pair is sent and the colubris is left without needed page links. ... mysql> select * from radreply where username like '%hawth%'; +-----+--------------+-----------------+----+----------------------------------------------------------------------------+------+ | id | UserName | Attribute | op | Value | note | +-----+--------------+-----------------+----+----------------------------------------------------------------------------+------+ | 2 | hawth_cn3000 | Colubris-AVPair | = | login-url=http://xx.xx.xx.xx/hotspots/hawthorn/login.html?loginurl=%l | NULL | | 3 | hawth_cn3000 | Colubris-AVPair | = | transport-page=http://xx.xx.xx.xx/hotspots/hawthorn/transport.html | NULL |
Use "+=" for the operators. See doc/rlm_sql for reasons why. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Use "+=" for the operators. See doc/rlm_sql for reasons why.
Still, after updating instances of '=' to '+=', we get: Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' How can I tell what operator/suffix they refer to? I can see no errors further into the output, and the following is now sent: Sending Access-Accept of id 217 to xxx.xx.127.162 port 2048 Colubris-AVPair += "login-url=http://xx.xxx.170.7/hotspots/hawthorn/login.html?loginurl=%l" Colubris-AVPair += "transport-page=http://xx.xxx.170.7/hotspots/hawthorn/transport.html" Colubris-AVPair += "session-page=http://xx.xxx.170.7/hotspots/hawthorn/session.html" Colubris-AVPair += "fail-page=http://xx.xxx.170.7/hotspots/hawthorn/fail.html" Colubris-AVPair += "logo=http://xx.xxx.170.7/hotspots/hawthorn/signonpic.jpg" Colubris-AVPair += "access-list=loginserver,ACCEPT,tcp,65.160.170.7,all" Colubris-AVPair += "use-access-list=loginserver" Colubris-AVPair += "welcome-url=http://xx.xxx.170.7/hotspots/hawthorn/welcome/index.html" Colubris-AVPair += "default-user-smtp-redirect=smtp-relay.xxxx.net" Colubris-AVPair += "white-list=all,www.xxxxxxxx.com" Colubris-AVPair += "mac-address=00-0F-B0-55-3D-45,hawthorn_guest,connect" Colubris-AVPair += "mac-address=00-0d-28-f0-dc-94,hawth_cn3000_00-0d-28-f0-dc-94,guest_connect" Colubris-AVPair += "mac-address=00-0d-28-e6-a7-fd,hawth_cn3000_00-0d-28-e6-a7-fd,guest_connect" Colubris-AVPair += "mac-address=00-0d-28-f0-dc-1a,hawth_cn3000_00-0d-28-f0-dc-1a,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-eb-88-4a,hawth_cn3000_00-0d-29-eb-88-4a,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-eb-87-e5,hawth_cn3000_00-0d-29-eb-87-e5,guest_connect" Colubris-AVPair += "mac-address=00-0d-28-f0-dc-09,hawth_cn3000_00-0d-28-f0-dc-09,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-eb-8a-a3,hawth_cn3000_00-0d-29-eb-8a-a3,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-eb-8a-98,hawth_cn3000_00-0d-29-eb-8a-98,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-eb-88-87,hawth_cn3000_00-0d-29-eb-88-87,guest_connect" Colubris-AVPair += "mac-address=00-0d-29-39-03-59,hawth_cn3000_00-0d-29-39-03-59,guest_connect" Colubris-AVPair += "mac-address=00-0c-85-47-b6-26,hawth_cn3000_00-0c-85-47-b6-26,guest_connect" Colubris-AVPair += "mac-address=00-14-BF-03-AA-37,hawthorn_0014BF03AA37,hawthorn_web" Finished request 0 -- Regards, Andrew Long
On Friday 05 January 2007 12:01, Andrew Long wrote:
Use "+=" for the operators. See doc/rlm_sql for reasons why.
Still, after updating instances of '=' to '+=', we get:
Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '=='
How can I tell what operator/suffix they refer to?
$ grep -ri Suffix /etc/raddb/* If that shows nothing, then it's being pulled from a database or other flat file. Check those other locations for any Suffix attributes. -Kevin
Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '=='
How can I tell what operator/suffix they refer to?
$ grep -ri Suffix /etc/raddb/*
If that shows nothing, then it's being pulled from a database or other flat file. Check those other locations for any Suffix attributes.
-Kevin
Here are all references to "suffix" in the config files...(not counting some comments) There are no instances in any sql tables. (radiusd.conf) # 'username@realm' # realm suffix { format = suffix delimiter = "@" ---------------------- # 'username%realm' # realm realmpercent { format = suffix delimiter = "%" ---------------------- # '@realm', and decide whether or not to proxy, based on # that. # realmslash suffix ------------------- # Accounting requests are generally proxied to the same # home server as authentication requests. # realmslash suffix ------------------- ------------------- (HINTS) DEFAULT Suffix = ".ppp", Strip-User-Name = Yes Hint = "PPP", Service-Type = Framed-User, Framed-Protocol = PPP DEFAULT Suffix = ".slip", Strip-User-Name = Yes Hint = "SLIP", Service-Type = Framed-User, Framed-Protocol = SLIP DEFAULT Suffix = ".cslip", Strip-User-Name = Yes Hint = "CSLIP", Service-Type = Framed-User, Framed-Protocol = SLIP, Framed-Compression = Van-Jacobson-TCP-IP --- Can you see any problem? -Andrew
On Friday 05 January 2007 16:40, Andrew Long wrote:
Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' (HINTS) DEFAULT Suffix = ".ppp", Strip-User-Name = Yes DEFAULT Suffix = ".slip", Strip-User-Name = Yes DEFAULT Suffix = ".cslip", Strip-User-Name = Yes
Can you see any problem?
-Andrew
3 "invalid operator" messages from debug mode... 3 lines in the hints file with the Suffix attribute. I think we have a winner. See 'man 5 users' or the Wiki Operators page to see why that is invalid. I think the hints file in the latest release (1.1.4) has correct defaults. -Kevin
participants (4)
-
Alan DeKok -
Andrew Long -
Kevin Bonner -
Long