Hello Cory -
As mentioned previously, you can either do this in a hook, or just
redefine the USR-Connect-Speed and Ascend-Xmit-Rate to
"Connect-Speed" in the dictionary.
regards
Hugh
At 13:21 -0500 01/1/12, Cory Visi wrote:
>Ok, I'm beginning to see why everyone suggested I start with the base
>dictionary and add stuff. Basically, we primarily use USR gear here, so my
>Connect-Speed is really a USR-Connect-Speed (i.e. a 1 or 2 digit number
>that maps to a real connect speed).
>
>So what I really want to do is have a Connect-Speed value that works with
>both Ascend gear and USR gear. I am open to suggestions, as I'm not sure
>what the best way to do this would be.
>
>(I think I would need to map the USR vendor attributes to a
>USR-Connect-Speed then copy it to the Connect-Speed variable, and for
>Ascend, use Ascend-Xmit-Rate and copy that to Connect-Speed.)
>
>Thank you again,
>
>Cory Visi
>DiscoverNet, Inc.
>
>On Fri, 12 Jan 2001, Hugh Irvine wrote:
>
>>
>> Hello Cory -
>>
>> On Friday 12 January 2001 08:31, Cory Visi wrote:
>> > Sorry if this is a duplicate send, but I don't think I was subscribed to
>> > the list the first time I sent this.
>> > ---
>> >
>> > Previously, I was using Radiator to do authentication with our USR
>> > HiperArc unit. We have recently started using an external dialup source to
>> > offload some of the call volume. This external source happens to be using
>> > Ascend gear so I had to make some changes to the dictionary file.
>> >
>> > I started with dictionary.usr then took all the Vendor 529
>> > (Ascend) VENDORATTR lines from dictionary.ascend2 and stuck them on the
>> > bottom.
>> >
>> > After doing this, I still have a few vendor attributes that I can't find
>> > in any dictionaries (even the latest: 10-Jan-2001 17:26).
>> >
>> > This is coming from our USR HiperARC (this has always been a problem):
>> >
>> > Thu Jan 11 12:08:58 2001: ERR: Attribute number 1 (vendor 9) is not
>> > defined in your dictionary
>> >
>> > These are coming from an external Ascend unit:
>> >
>> > Thu Jan 11 12:04:12 2001: ERR: Attribute number 86 (vendor 529) is not
>> > defined in your dictionary
>> > Thu Jan 11 12:04:12 2001: ERR: Attribute number 13 (vendor 529) is not
>> > defined in your dictionary
>> > Thu Jan 11 13:03:17 2001: ERR: Attribute number 66 (vendor 529) is not
>> > defined in your dictionary
>> > Thu Jan 11 13:03:17 2001: ERR: Attribute number 67 (vendor 529) is not
>> > defined in your dictionary
>> >
>>
>> I don't have these either, but you can always add temporary definitions like
>> this to at least stop the log messages:
>>
>> VENDORATTR 9 USR-Temp-Attr-1 1 string
>>
>> VENDORATTR 529 Ascend-Temp-Attr-13 13 string
>> VENDORATTR 529 Ascend-Temp-Attr-66 66 string
>> VENDORATTR 529 Ascend-Temp-Attr-67 67 string
>> VENDORATTR 529 Ascend-Temp-Attr-86 86 string
>>
>> You will have to chase your NAS vendor(s) for the correct definitions (and
>> when you get them, please send us a copy so we can update the dictionary).
>>
>> > In addition, I was able to get most of the Ascend vendor attributes
>> > however they all map to attribute names Ascend-*. Is there a way to
>> > have this integrate with normal Radiator variables so I don't have to
>> > change my accounting information? What am I missing here?
>> >
>> > For instance, for users calling into the Ascend gear, there is no Connect
>> > speed or Modulation Type in the session database. My Query string for the
>> > session database uses "Connect-Speed" and "Modulation-Type". I'm guessing
>> > that this data is coming from the Ascend gear, but getting placed in an
>> > Ascend-* variable, so how would I "map" this over to the usual
>> > respective Radiator attributes?
>> >
>>
>> You will have to have a look at a trace 4 debug to see what attributes are
>> actually present in the radius packets coming from the various
>>NAS(s). If you
> > send me a copy of your configuration file (no secrets) together with some
>> relevant trace 4 output, I'll have a look and try to make some suggestions.
>>
>> regards
>>
>> Hugh
>>
>> --
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>>
>
>
>===
>Archive at http://www.starport.net/~radiator/
>Announcements on [EMAIL PROTECTED]
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.
--
NB: I am travelling this week, so there may be delays in our correspondence.
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
