[RADIATOR] Issues with VSA

[Brandon Shiers]

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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200804/68827baa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dictionary.canopy161
Type: application/octet-stream
Size: 9895 bytes
Desc: dictionary.canopy161
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200804/68827baa/attachment.obj>