Hi Heikki - I was doing some testing with this dictionary and it works fine (except for the confusion around the duplicate names).
However, I did find something unexpected. This works in the configuration file: DictionaryFile %D/dictionary,%D/dictionary.canopy161 BUT this doesn’t: DictionaryFile %D/dictionary, %D/dictionary.canopy161 The space gets interpreted as part of the second file name. *sigh* yet another foot gun (that has been there from the very beginning I’m guessing) BTW - this is with Radiator-4.24-44 on MacOS Catalina cheers Hugh > On 5 Aug 2020, at 03:20, Brandon Shiers <[email protected]> wrote: > > Heikki, > > I've attached a copy of their dictionary file. For you to peruse. Thank you > for your other feedback. Once I can get the reply attributes passing back > from the flat file I'll switch back over to the database and try with the > Cleartext-Password changed to User-Password. > > Thanks much for your assistance! > > > Brandon Shiers, RF Engineer > > 937 West Main Street > Riverton, WY 82501 > > 307.857.6704 (o) > 307.840.2366 (c) > 307.856.1499 (f) > [email protected] > > > > > From: radiator <[email protected]> on behalf of Heikki > Vatiainen <[email protected]> > Sent: Tuesday, August 4, 2020 11:03 AM > To: [email protected] > Subject: Re: [RADIATOR] Issues with VSA > > On 4.8.2020 19.40, Brandon Shiers wrote: > > > I’m trying to get some Cambium VSA’s passed back to some subscriber > > modules. I have the latest Cambium dictionary loaded up in my > > dictionary file. I get authenticated and a trace 4 shows the attributes > > in the reply packet but when I packet sniff them, I am seeing for all > > the Cambium specific VSA’s under the VSA I get an unknown attribute and > > then the attribute ID out of the dictionary file. The AVP does identify > > the packet as Vendor-Specific (26) and finds the vendor (Motorola 161), > > which is , which is actually Cambium now for the product we are using. > > > > Any ideas on what I’m doing wrong? I have confirmed I have the most > > recent dictionary file loaded from the vendor and radiator doesn’t > > complain about the dictionary file on startup. > > Looks like there are Cambium-Canopy and Motorol-Canopy attributes in > circulation. This might be the reason why you see unexpected attributes. > > If you can pass me the definitions of the Cambium/Motorola/Canopy > attributes you have with VENDOR id, attribute names, codes and types > I'll see how well they match Radiator dictionary. > > In addition to this, documentation of what the devices expect would be > needed to know which attributes to return. > > I'm sure this gets solved but sometimes the definitions from different > sources are not as clear or consistently named as they could. > > Thanks, > Heikki > > > -- > Heikki Vatiainen <[email protected]> > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, > EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. > _______________________________________________ > radiator mailing list > [email protected] > https://lists.open.com.au/mailman/listinfo/radiator > <dictionary.canopy161>_______________________________________________ > radiator mailing list > [email protected] > https://lists.open.com.au/mailman/listinfo/radiator -- Hugh Irvine [email protected] Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
