I am currently working with the CVS (1.1.0) HEAD version of FreeRADIUS. It is using the SQL module with the Lucent 16bit atributes turned on. To make sure we have the most attributes available, I have merged the Ascend dictionary (more specifically, the just the VALUEs), because the CVS dictionary.lucent had none. Just attributes. I have been using Lucent-Modem-Modulation (code 305) and Lucent-Modulation (code 20106) in the SQL statements to discern which one would be coming from our NAS (MAX TNT running TAOS v11), and it looks as though Lucent-Modem-Modulation is currently being sent. Now, while I was testing this last week I was receiving: Lucent-Modem = v90/v34/v92/etc instead of this week: Lucent-Modem-Modulation = 1/2/18/etc Is there a possible reason it used code 20106 last week and now code 305? Also, is there a reason I'm being given numerical values back instead of what they represent? Here is the current state of the relevant portion of our dictionary.lucent: ATTRIBUTE Lucent-Modem-Modulation 305 integer ... ... ATTRIBUTE Lucent-Modulation 20106 integer .. .. VALUE Lucent-Modulation v90 1 VALUE Lucent-Modulation v34 2 VALUE Lucent-Modulation v17 3 VALUE Lucent-Modulation v23 4 VALUE Lucent-Modulation v21 5 VALUE Lucent-Modulation k56flex 6 VALUE Lucent-Modulation v22bis 7 VALUE Lucent-Modulation v32 8 VALUE Lucent-Modulation bell212 9 VALUE Lucent-Modulation bell103 10 VALUE Lucent-Modulation v22 11 VALUE Lucent-Modulation vFC 12 VALUE Lucent-Modulation v33 13 VALUE Lucent-Modulation bell208 14 VALUE Lucent-Modulation v29 15 VALUE Lucent-Modulation v27 16 VALUE Lucent-Modulation none 17 VALUE Lucent-Modulation v92 18 VALUE Lucent-Modem-Modulation v90 1 VALUE Lucent-Modem-Modulation v34 2 VALUE Lucent-Modem-Modulation v17 3 VALUE Lucent-Modem-Modulation v23 4 VALUE Lucent-Modem-Modulation v21 5 VALUE Lucent-Modem-Modulation k56flex 6 VALUE Lucent-Modem-Modulation v22bis 7 VALUE Lucent-Modem-Modulation v32 8 VALUE Lucent-Modem-Modulation bell212 9 VALUE Lucent-Modem-Modulation bell103 10 VALUE Lucent-Modem-Modulation v22 11 VALUE Lucent-Modem-Modulation vFC 12 VALUE Lucent-Modem-Modulation v33 13 VALUE Lucent-Modem-Modulation bell208 14 VALUE Lucent-Modem-Modulation v29 15 VALUE Lucent-Modem-Modulation v27 16 VALUE Lucent-Modem-Modulation none 17 VALUE Lucent-Modem-Modulation v92 18 Thanks, Wes
Wesley Spadola <wspadola@porchlight.ca> wrote:
Now, while I was testing this last week I was receiving: Lucent-Modem = v90/v34/v92/etc instead of this week: Lucent-Modem-Modulation = 1/2/18/etc
The NAS sends those attributes, and FreeRADIUS logs them.
Is there a possible reason it used code 20106 last week and now code 305? Also, is there a reason I'm being given numerical values back instead of what they represent? Here is the current state of the relevant portion of our dictionary.lucent:
What changed in your system the last week? Alan DeKok.
Alan DeKok wrote:
The NAS sends those attributes, and FreeRADIUS logs them.
What changed in your system the last week?
The only thing I can remember changing is the dictionary, making sure that those ATTRIBUTE and VALUE lines were there for both Lucent-Modem-Modulation and Lucent-Modulation (not knowing which the NAS was going to send at first). In testing this behaviour, I have taken a few entries (Attribute/Value lines only) from the detail and piped them to radclient. The Lucent-Modem-Modulation = 1/2/18 lines get decoded by the radiusd server as Lucent-Modem-Modulation = v90/v34/v92 etc. However I use radiusd in its radrelay mode, having copied the detail file I have to location radiusd expects, radiusd does start to read its detail file, but does not decode the lines, it only shows through its accounting SQL statements that Lucent-Modem-Modulation = 1/2/18 etc.
Wesley Spadola <wspadola@porchlight.ca> wrote:
However I use radiusd in its radrelay mode, having copied the detail file I have to location radiusd expects, radiusd does start to read its detail file, but does not decode the lines, it only shows through its accounting SQL statements that Lucent-Modem-Modulation = 1/2/18 etc.
I'm not sure what to suggest, sorry. Alan DeKok.
participants (2)
-
Alan DeKok -
Wesley Spadola