<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div>
<div>
<div>
<div style="direction: ltr;">Thanks guys!  I had it loaded into my main dictionary file.  I’ll back that out and apply the suggested config tomorrow and see if I get any further.  I am running Radiator 4.19 not sure if that will make a big difference or not.<span id="ms-outlook-ios-cursor"></span></div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature">Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>
</div>
<div> </div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>From:</b> radiator <radiator-bounces@lists.open.com.au> on behalf of Hugh Irvine <hugh@open.com.au><br>
<b>Sent:</b> Tuesday, August 4, 2020 6:41 PM<br>
<b>To:</b> Heikki Vatiainen<br>
<b>Cc:</b> radiator@lists.open.com.au<br>
<b>Subject:</b> Re: [RADIATOR] Issues with VSA
<div> </div>
</font></div>
<br>
Hi Heikki -<br>
<br>
I was doing some testing with this dictionary and it works fine (except for the confusion around the duplicate names).<br>
<br>
However, I did find something unexpected.<br>
<br>
This works in the configuration file:<br>
<br>
DictionaryFile %D/dictionary,%D/dictionary.canopy161<br>
<br>
BUT this doesn’t:<br>
<br>
DictionaryFile %D/dictionary, %D/dictionary.canopy161<br>
<br>
The space gets interpreted as part of the second file name.<br>
<br>
*sigh*<br>
<br>
yet another foot gun (that has been there from the very beginning I’m guessing)<br>
<br>
BTW - this is with Radiator-4.24-44 on MacOS Catalina<br>
<br>
cheers<br>
<br>
Hugh<br>
<br>
<br>
> On 5 Aug 2020, at 03:20, Brandon Shiers <brandon.shiers@cerento.com> wrote:<br>
> <br>
> Heikki,<br>
> <br>
> 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.<br>
> <br>
> Thanks much for your assistance!<br>
> <br>
> <br>
> Brandon Shiers, RF Engineer<br>
> <br>
> 937 West Main Street<br>
> Riverton, WY 82501<br>
> <br>
> 307.857.6704 (o)<br>
> 307.840.2366 (c)<br>
> 307.856.1499 (f)<br>
> brandon.shiers@cerento.com<br>
> <br>
> <br>
> <br>
> <br>
> From: radiator <radiator-bounces@lists.open.com.au> on behalf of Heikki Vatiainen <hvn@open.com.au><br>
> Sent: Tuesday, August 4, 2020 11:03 AM<br>
> To: radiator@lists.open.com.au<br>
> Subject: Re: [RADIATOR] Issues with VSA<br>
> <br>
> On 4.8.2020 19.40, Brandon Shiers wrote:<br>
> <br>
> > I’m trying to get some Cambium VSA’s passed back to some subscriber <br>
> > modules. I have the latest Cambium dictionary loaded up in my <br>
> > dictionary file. I get authenticated and a trace 4 shows the attributes <br>
> > in the reply packet but when I packet sniff them, I am seeing for all <br>
> > the Cambium specific VSA’s under the VSA I get an unknown attribute and <br>
> > then the attribute ID out of the dictionary file. The AVP does identify <br>
> > the packet as Vendor-Specific (26) and finds the vendor (Motorola 161), <br>
> > which is , which is actually Cambium now for the product we are using.<br>
> > <br>
> > Any ideas on what I’m doing wrong? I have confirmed I have the most <br>
> > recent dictionary file loaded from the vendor and radiator doesn’t <br>
> > complain about the dictionary file on startup.<br>
> <br>
> Looks like there are Cambium-Canopy and Motorol-Canopy attributes in <br>
> circulation. This might be the reason why you see unexpected attributes.<br>
> <br>
> If you can pass me the definitions of the Cambium/Motorola/Canopy <br>
> attributes you have with VENDOR id, attribute names, codes and types <br>
> I'll see how well they match Radiator dictionary.<br>
> <br>
> In addition to this, documentation of what the devices expect would be <br>
> needed to know which attributes to return.<br>
> <br>
> I'm sure this gets solved but sometimes the definitions from different <br>
> sources are not as clear or consistently named as they could.<br>
> <br>
> Thanks,<br>
> Heikki<br>
> <br>
> <br>
> -- <br>
> Heikki Vatiainen <hvn@open.com.au><br>
> <br>
> Radiator: the most portable, flexible and configurable RADIUS server<br>
> anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,<br>
> EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,<br>
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.<br>
> _______________________________________________<br>
> radiator mailing list<br>
> radiator@lists.open.com.au<br>
> https://lists.open.com.au/mailman/listinfo/radiator<br>
> <dictionary.canopy161>_______________________________________________<br>
> radiator mailing list<br>
> radiator@lists.open.com.au<br>
> https://lists.open.com.au/mailman/listinfo/radiator<br>
<br>
<br>
--<br>
<br>
Hugh Irvine<br>
hugh@open.com.au<br>
<br>
Radiator: the most portable, flexible and configurable RADIUS server <br>
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, <br>
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, <br>
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,<br>
DIAMETER, SIM, etc. <br>
Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc.<br>
<br>
_______________________________________________<br>
radiator mailing list<br>
radiator@lists.open.com.au<br>
https://lists.open.com.au/mailman/listinfo/radiator</div>
</body>
</html>