[RADIATOR] Issues with VSA

[Hugh Irvine]

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 <brandon.shiers at cerento.com> 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)
> brandon.shiers at cerento.com
> 
> 
> 
> 
> From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
> Sent: Tuesday, August 4, 2020 11:03 AM
> To: radiator at lists.open.com.au
> 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 <hvn at open.com.au>
> 
> 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
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator
> <dictionary.canopy161>_______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
hugh at open.com.au

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.