need help for adding VSA dictionary in Freeradius 2.1.6
Hello, I have problem in adding new VSA dictionary file into Freeradius 2.1.6. Below you can find the steps I performed; - create the file named *dictionary.alcatel.esam* with the following content in */usr/local/share/freeradius/* folder; # # VENDOR Alcatel-ESAM 637 BEGIN-VENDOR Alcatel-ESAM ATTRIBUTE A-ESAM-VRF-Name 0x0700 string ATTRIBUTE A-ESAM-Vlan-Id 0x0701 integer ATTRIBUTE A-ESAM-QOS-Profile-Name 0x0702 string ATTRIBUTE A-ESAM-QOS-Params 0x0703 string ATTRIBUTE A-ESAM-Termination-Cause 0x0704 integer # . . END-VENDOR Alcatel-ESAM - add the line below into */usr/local/share/freeradius/dictionary* file; $INCLUDE dictionary.netscreen $INCLUDE dictionary.networkphysics $INCLUDE dictionary.nexans $INCLUDE dictionary.ntua $INCLUDE dictionary.nokia *$INCLUDE dictionary.alcatel.esam* - start radiusd with debugging option. I get the following error message (radiusd -X ) ; *including dictionary file /usr/local/etc/raddb/dictionary Errors reading dictionary: dict_init: /usr/local/share/freeradius/dictionary.alcatel.esam[9]: dict_init: /usr/local/share/freeradius/dictionary.alcatel.esam[9]: * According to my analysis, freeradius does not like the hex values in the VSA dictionary file i.e : 0x0700 . So I tried to make it decimal which is 1792 but still getting the same error message. It seems those attribute numbers should be in a lower range, because if I start from 1 , and I don't get the message in question. But in this case, the attribute becomes unknown resulting in having not applied while user authentication. Is there a way to overcome this problem ? Thanks Salim Engin
Salim Engin wrote:
I have problem in adding new VSA dictionary file into Freeradius 2.1.6. Below you can find the steps I performed; ... According to my analysis, freeradius does not like the hex values in the VSA dictionary file i.e : 0x0700 .
In 2.1.x, it can handle hex values just fine.
So I tried to make it decimal which is 1792 but still getting the same error message. It seems those attribute numbers should be in a lower range, because if I start from 1 , and I don't get the message in question. But in this case, the attribute becomes unknown resulting in having not applied while user authentication.
The default VSA format is an 8 bit "type" field. 0x0700 doesn't fit within an 8-bit field. What is the format for Alcatel-Esam attributes? Do you have documentation from Alcatel saying what the format is, or a dictionary from another vendor describing the format? Alan DeKok.
Hi, Thanks for the reply. What I have about the Alcatel VSA is 1- From its customer documentation; General Vendor ID 637 is used for 7302 ISAM. The vendor specific attribute type has a length of two bytes long where the highest byte is the project ID and the lowest byte is the project specific attribute ID. The project ID 7 is assigned to 7302 ISAM project. This means that the vendor specific attribute range from 1792 to 2047 will be used for the 7302 ISAM. VRF-Name • Vendor Type: 1792 • Vendor Length: 4 < length < 35 • Vendor Value: STRING • Packet: Access-Accept VLAN-ID • Vendor Type: 1793 • Vendor Length: 7 • Vendor Value: INTEGER • Packet: Access-Accept . . . 2- The complete dictionary file from TRS ( Technical Requirements Specific) ; # # Alcatel ESAM's VSA's, from TRS # # VENDOR Alcatel-ESAM 637 BEGIN-VENDOR Alcatel-ESAM ATTRIBUTE A-ESAM-VRF-Name 0x0700 string ATTRIBUTE A-ESAM-Vlan-Id 0x0701 integer ATTRIBUTE A-ESAM-QOS-Profile-Name 0x0702 string ATTRIBUTE A-ESAM-QOS-Params 0x0703 string ATTRIBUTE A-ESAM-Termination-Cause 0x0704 integer # # Integer Translations # # A-ESAM-Termination-Cause Values VALUE A-ESAM-Termination-Cause Unknown-VRF 1 VALUE A-ESAM-Termination-Cause No-VRF 2 VALUE A-ESAM-Termination-Cause Unknown-Vlan 3 VALUE A-ESAM-Termination-Cause No-Vlan 4 VALUE A-ESAM-Termination-Cause Unknown-Pool-Id 5 VALUE A-ESAM-Termination-Cause Pool-Admin-Locked 6 VALUE A-ESAM-Termination-Cause No-Pool-Id 7 VALUE A-ESAM-Termination-Cause Pool-VRF-Inconsistent 8 VALUE A-ESAM-Termination-Cause Unknown-QOS-Profile 9 VALUE A-ESAM-Termination-Cause QOS-Params-Syntax-Err 10 VALUE A-ESAM-Termination-Cause IP-Addr-In-Use 11 VALUE A-ESAM-Termination-Cause No-IP-Addr-Available 12 VALUE A-ESAM-Termination-Cause No-User-IP-Addr 13 VALUE A-ESAM-Termination-Cause Missing-Attributes 14 #VSA for Operator Authentication ATTRIBUTE A_AL_Maintenance 0x0600 integer ATTRIBUTE A_AL_Provisioning 0x0601 integer ATTRIBUTE A_AL_TL1_Security 0x0602 integer ATTRIBUTE A_AL_Test 0x0603 integer ATTRIBUTE A_AL_AAA 0x0709 integer ATTRIBUTE A_AL_ATM 0x070A integer ATTRIBUTE A_AL_Alarm 0x070B integer ATTRIBUTE A_AL_DHCP 0x070C integer ATTRIBUTE A_AL_EQP 0x070D integer ATTRIBUTE A_AL_IGMP 0x070E integer ATTRIBUTE A_AL_CPEProxy 0x070F integer ATTRIBUTE A_AL_IP 0x0710 integer ATTRIBUTE A_AL_PPPoE 0x0711 integer ATTRIBUTE A_AL_QoS 0x0712 integer ATTRIBUTE A_AL_SWMgt 0x0713 integer ATTRIBUTE A_AL_Transport 0x0714 integer ATTRIBUTE A_AL_VLAN 0x0715 integer ATTRIBUTE A_AL_XDSL 0x0716 integer ATTRIBUTE A_AL_Security 0x0717 integer ATTRIBUTE A_AL_Cluster 0x0718 integer ATTRIBUTE A_AL_Prompt 0x0719 string ATTRIBUTE A_AL_Pwd_Timeout 0x071A integer ATTRIBUTE A_AL_Description 0x071B string ATTRIBUTE A_AL_SLOT_NUMBERING 0x071C integer ####FTTU TL1 values############################################### ATTRIBUTE A_AL_MAINTENANCE_BACKWARD 0x0705 integer ATTRIBUTE A_AL_PROVISIONING_BACKWARD 0x0706 integer ATTRIBUTE A_AL_TL1_SECURITY_BACKWARD 0x0707 integer ATTRIBUTE A_AL_TEST_BACKWARD 0x0708 integer ################################################################### # A_AL_Maintenance Values VALUE A_AL_Maintenance Alcatel-No-Maint-Priv-Level 0 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-1 1 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-2 2 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-3 3 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-4 4 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-5 5 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-6 6 VALUE A_AL_Maintenance Alcatel-Maint-Priv-Level-7 7 # A_AL_Provisioning Values VALUE A_AL_Provisioning Alcatel-No-Maint-Priv-Level 0 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-1 1 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-2 2 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-3 3 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-4 4 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-5 5 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-6 6 VALUE A_AL_Provisioning Alcatel-Maint-Priv-Level-7 7 # A_AL_Security Values VALUE A_AL_Security Alcatel-No-Maint-Priv-Level 0 VALUE A_AL_Security Alcatel-Maint-Priv-Level-1 1 VALUE A_AL_Security Alcatel-Maint-Priv-Level-2 2 VALUE A_AL_Security Alcatel-Maint-Priv-Level-3 3 VALUE A_AL_Security Alcatel-Maint-Priv-Level-4 4 VALUE A_AL_Security Alcatel-Maint-Priv-Level-5 5 VALUE A_AL_Security Alcatel-Maint-Priv-Level-6 6 VALUE A_AL_Security Alcatel-Maint-Priv-Level-7 7 # A_AL_Test Values VALUE A_AL_Test Alcatel-No-Maint-Priv-Level 0 VALUE A_AL_Test Alcatel-Maint-Priv-Level-1 1 VALUE A_AL_Test Alcatel-Maint-Priv-Level-2 2 VALUE A_AL_Test Alcatel-Maint-Priv-Level-3 3 VALUE A_AL_Test Alcatel-Maint-Priv-Level-4 4 VALUE A_AL_Test Alcatel-Maint-Priv-Level-5 5 VALUE A_AL_Test Alcatel-Maint-Priv-Level-6 6 VALUE A_AL_Test Alcatel-Maint-Priv-Level-7 7 # A_AL_AAA Value VALUE A_AL_AAA Alcatel-No-Priv 0 VALUE A_AL_AAA Alcatel-Read-Priv 1 VALUE A_AL_AAA Alcatel-Write-Priv 2 VALUE A_AL_AAA Alcatel-RW-Priv 3 # A_AL_ATM Value VALUE A_AL_ATM Alcatel-No-Priv 0 VALUE A_AL_ATM Alcatel-Read-Priv 1 VALUE A_AL_ATM Alcatel-Write-Priv 2 VALUE A_AL_ATM Alcatel-RW-Priv 3 # A_AL_Alarm Value VALUE A_AL_Alarm Alcatel-No-Priv 0 VALUE A_AL_Alarm Alcatel-Read-Priv 1 VALUE A_AL_Alarm Alcatel-Write-Priv 2 VALUE A_AL_Alarm Alcatel-RW-Priv 3 # A_AL_DHCP Value VALUE A_AL_DHCP Alcatel-No-Priv 0 VALUE A_AL_DHCP Alcatel-Read-Priv 1 VALUE A_AL_DHCP Alcatel-Write-Priv 2 VALUE A_AL_DHCP Alcatel-RW-Priv 3 # A_AL_EQP Value VALUE A_AL_EQP Alcatel-No-Priv 0 VALUE A_AL_EQP Alcatel-Read-Priv 1 VALUE A_AL_EQP Alcatel-Write-Priv 2 VALUE A_AL_EQP Alcatel-RW-Priv 3 # A_AL_IGMP Value VALUE A_AL_IGMP Alcatel-No-Priv 0 VALUE A_AL_IGMP Alcatel-Read-Priv 1 VALUE A_AL_IGMP Alcatel-Write-Priv 2 VALUE A_AL_IGMP Alcatel-RW-Priv 3 # A_AL_CPEProxy Value VALUE A_AL_CPEProxy Alcatel-No-Priv 0 VALUE A_AL_CPEProxy Alcatel-Read-Priv 1 VALUE A_AL_CPEProxy Alcatel-Write-Priv 2 VALUE A_AL_CPEProxy Alcatel-RW-Priv 3 # A_AL_IP Value VALUE A_AL_IP Alcatel-No-Priv 0 VALUE A_AL_IP Alcatel-Read-Priv 1 VALUE A_AL_IP Alcatel-Write-Priv 2 VALUE A_AL_IP Alcatel-RW-Priv 3 # A_AL_PPPoE Value VALUE A_AL_PPPoE Alcatel-No-Priv 0 VALUE A_AL_PPPoE Alcatel-Read-Priv 1 VALUE A_AL_PPPoE Alcatel-Write-Priv 2 VALUE A_AL_PPPoE Alcatel-RW-Priv 3 # A_AL_QoS Value VALUE A_AL_QoS Alcatel-No-Priv 0 VALUE A_AL_QoS Alcatel-Read-Priv 1 VALUE A_AL_QoS Alcatel-Write-Priv 2 VALUE A_AL_QoS Alcatel-RW-Priv 3 # A_AL_SWMgt Value VALUE A_AL_SWMgt Alcatel-No-Priv 0 VALUE A_AL_SWMgt Alcatel-Read-Priv 1 VALUE A_AL_SWMgt Alcatel-Write-Priv 2 VALUE A_AL_SWMgt Alcatel-RW-Priv 3 # A_AL_Transport Value VALUE A_AL_Transport Alcatel-No-Priv 0 VALUE A_AL_Transport Alcatel-Read-Priv 1 VALUE A_AL_Transport Alcatel-Write-Priv 2 VALUE A_AL_Transport Alcatel-RW-Priv 3 # A_AL_VLAN Value VALUE A_AL_VLAN Alcatel-No-Priv 0 VALUE A_AL_VLAN Alcatel-Read-Priv 1 VALUE A_AL_VLAN Alcatel-Write-Priv 2 VALUE A_AL_VLAN Alcatel-RW-Priv 3 # A_AL_XDSL Value VALUE A_AL_XDSL Alcatel-No-Priv 0 VALUE A_AL_XDSL Alcatel-Read-Priv 1 VALUE A_AL_XDSL Alcatel-Write-Priv 2 VALUE A_AL_XDSL Alcatel-RW-Priv 3 # A_AL_Security Value VALUE A_AL_Security Alcatel-No-Priv 0 VALUE A_AL_Security Alcatel-Read-Priv 1 VALUE A_AL_Security Alcatel-Write-Priv 2 VALUE A_AL_Security Alcatel-RW-Priv 3 # A_AL_Cluster Value VALUE A_AL_Cluster Alcatel-No-Priv 0 VALUE A_AL_Cluster Alcatel-Read-Priv 1 VALUE A_AL_Cluster Alcatel-Write-Priv 2 VALUE A_AL_Cluster Alcatel-RW-Priv 3 # A_AL_Cluster Value VALUE A_AL_SLOT_NUMBERING SLOT_NUMBERING_TYPE 1 VALUE A_AL_SLOT_NUMBERING SLOT_NUMBERING_POSITION 2 VALUE A_AL_SLOT_NUMBERING SLOT_NUMBERING_LEGACY 3 END-VENDOR Alcatel-ESAM Does this answer your question ? Thanks. Salim Engin On Fri, Sep 11, 2009 at 12:40 PM, Alan DeKok <aland@deployingradius.com>wrote:
Salim Engin wrote:
I have problem in adding new VSA dictionary file into Freeradius 2.1.6. Below you can find the steps I performed; ... According to my analysis, freeradius does not like the hex values in the VSA dictionary file i.e : 0x0700 .
In 2.1.x, it can handle hex values just fine.
So I tried to make it decimal which is 1792 but still getting the same error message. It seems those attribute numbers should be in a lower range, because if I start from 1 , and I don't get the message in question. But in this case, the attribute becomes unknown resulting in having not applied while user authentication.
The default VSA format is an 8 bit "type" field. 0x0700 doesn't fit within an 8-bit field.
What is the format for Alcatel-Esam attributes? Do you have documentation from Alcatel saying what the format is, or a dictionary from another vendor describing the format?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Salim Engin wrote:
1- From its customer documentation;
General Vendor ID 637 is used for 7302 ISAM. The vendor specific attribute type has a length of two bytes long where the highest byte is the project ID and the lowest byte is the project specific attribute ID. The project ID 7 is assigned to 7302 ISAM project. This means that the vendor specific attribute range from 1792 to 2047 will be used for the 7302 ISAM.
Ok... so I *presume* that means the data in the RADIUS packet is also 16 bits. I'll add a dictionary to git. You'll be able to try it in 2.1.7. Alan DeKok.
Alan, I was able to use Alcatel Esam VSA in Freeradius 2.1.7 . Thanks a lot for your help. Note: dictionary.alcatel.esam was not included in dictionary file ... I simply added it and it worked. Salim Engin On Sun, Sep 13, 2009 at 6:08 PM, Alan DeKok <aland@deployingradius.com>wrote:
Salim Engin wrote:
1- From its customer documentation;
General Vendor ID 637 is used for 7302 ISAM. The vendor specific attribute type has a length of two bytes long where the highest byte is the project ID and the lowest byte is the project specific attribute ID. The project ID 7 is assigned to 7302 ISAM project. This means that the vendor specific attribute range from 1792 to 2047 will be used for the 7302 ISAM.
Ok... so I *presume* that means the data in the RADIUS packet is also 16 bits.
I'll add a dictionary to git. You'll be able to try it in 2.1.7.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Salim Engin wrote:
I was able to use Alcatel Esam VSA in Freeradius 2.1.7 . Thanks a lot for your help. Note: dictionary.alcatel.esam was not included in dictionary file ... I simply added it and it worked.
Ok. I'll include it in the main dictionary file for 2.1.8. Alan DeKok.
I am hoping someone has encountered this before and might have suggestions how to work around. The access device in use is from a company called Juniper. I am using freeradius 2.1.6 (can upgrade to 2.1.7 if there is any advantage). Their Acct-Session-Id numbers are too large for the radutmp field. Acct-Session-Id=315138101 becomes Acct-Session-Id = "15138101" (the code automatically chops off the excess on the right apparently) This becomes a problem when trying to use the Simultaneous-Use functionality. Once a duplicate is suspected, and radcheck determines it is no longer active, it appears an accounting Stop is generated internally, with the s(truncated) ession id extracted from radutmp. ([sanenasport] expand: %{Acct-Session-Id} -> 15138101). I assume this stop is intended to eventually remove the 'stale' entry from radutmp? (There is a custom acctstop script that appears to hang - so I am not certian.) Has anyone come up with an eloquent solution for Acct-Session-Ids that are too large for radutmp? Has anyone come up with an alternate way of achieving the same result? Thanks, -craig __________ Information from ESET Smart Security, version of virus signature database 4415 (20090910) __________ The message was checked by ESET Smart Security. http://www.eset.com
Has anyone come up with an eloquent solution for Acct-Session-Ids that are too large for radutmp?
Has anyone come up with an alternate way of achieving the same result?
Use one of the SQL database options to store accounting/auth info, and do the simultaneous use checking.
The access device in use is from a company called Juniper. I am using freeradius 2.1.6 (can upgrade to 2.1.7 if there is any advantage).
Their Acct-Session-Id numbers are too large for the radutmp field. Acct-Session-Id=315138101 becomes Acct-Session-Id = "15138101" (the code automatically chops off the excess on the right apparently)
This becomes a problem when trying to use the Simultaneous-Use functionality. Once a duplicate is suspected, and radcheck determines it is no longer active, it appears an accounting Stop is generated internally, with the s(truncated) ession id extracted from radutmp. ([sanenasport] expand: %{Acct-Session-Id} -> 15138101). I assume this stop is intended to eventually remove the 'stale' entry from radutmp? (There is a custom acctstop script that appears to hang - so I am not certian.)
Has anyone come up with an eloquent solution for Acct-Session-Ids that are too large for radutmp?
Has anyone come up with an alternate way of achieving the same result?
Use sql for accounting. Ivan Kalik Kalik Informatika ISP
participants (5)
-
Alan DeKok -
Craig Campbell -
Ivan Kalik -
Phil Mayers -
Salim Engin