Hugh, I'm seeing much of the same in my trace4. When I do a wireshark capture I see the attribute handed back but it shows an unknown attribute in there even though I see the correct data getting passed back to the radio, but the radio won't accept it. Maybe I'm just getting hung up on what I'm seeing in the wireshark capture?
Thanks, 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] -----Original Message----- From: Hugh Irvine Sent: Tuesday, August 04, 2020 7:47 PM To: Brandon Shiers <[email protected]> Cc: Heikki Vatiainen <[email protected]>; [email protected] Subject: Re: [RADIATOR] Issues with VSA Hi Brandon - You can do it either way, I just find it simpler and clearer to keep dictionaries like this separate, especially for testing. Keep in mind that what you see on the wire is what is important, as different dictionaries may have different VSA definitions. Here is the users file I used: hugh Password=hugh Cambium-Canopy-LPULCIR = 1, Motorola-Canopy-LPULCIR =1 With this configuration file: Foreground LogStdout LogDir . DbDir . DictionaryFile %D/dictionary,%D/dictionary.canopy # User a lower trace level in production systems: Trace 4 # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with <Client DEFAULT> Secret mysecret </Client> <Handler> <AuthBy FILE> Filename %D/users.canopy </AuthBy> # Log accounting to a detail file AcctLogFileName %L/detail </Handler> which gives this result - you are seeing both the trace 4 debug from radiusd *and* the trace 4 debug from radpwtst notice the decode that uses the Motorola definition twice due to the way the dictionaries are parsed: Radiator-4.24-44 % perl radpwtst -user hugh -password hugh -noacct -trace 4 -dictionary dictionary,dictionary.canopy Wed Aug 5 10:31:18 2020: DEBUG: Reading dictionary file 'dictionary' Wed Aug 5 10:31:18 2020: DEBUG: Reading dictionary file 'dictionary.canopy' sending Access-Request Wed Aug 5 10:31:18 2020: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 1645 .... Code: Access-Request Identifier: 156 Authentic: <16><131><185>.<148>&<236><235><186>k<127><165>p<15><167><240> Attributes: User-Name = "hugh" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = <240>k<142><207><172><0><191><183>d<233><247><173><165><175><219><241> Wed Aug 5 10:31:18 2020: DEBUG: Packet dump: *** Received from 127.0.0.1 port 61052 .... Code: Access-Request Identifier: 156 Authentic: <16><131><185>.<148>&<236><235><186>k<127><165>p<15><167><240> Attributes: User-Name = "hugh" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = <240>k<142><207><172><0><191><183>d<233><247><173><165><175><219><241> Wed Aug 5 10:31:18 2020: DEBUG: Handling request with Handler '', Identifier '' Wed Aug 5 10:31:18 2020: DEBUG: SessINTERNAL: Deleting session for hugh, 203.63.154.1, 1234 Wed Aug 5 10:31:18 2020: DEBUG: Handling with Radius::AuthFILE: Wed Aug 5 10:31:18 2020: DEBUG: Radius::AuthFILE looks for match with 'hugh' [hugh] Wed Aug 5 10:31:18 2020: DEBUG: Radius::AuthFILE ACCEPT: : 'hugh' [hugh] Wed Aug 5 10:31:18 2020: DEBUG: AuthBy FILE result: ACCEPT, Wed Aug 5 10:31:18 2020: DEBUG: Access accepted for hugh Wed Aug 5 10:31:18 2020: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 61052 .... Code: Access-Accept Identifier: 156 Authentic: <15><214><217>><207><22><138>A<134><7><245><198><186><217><205><233> Attributes: Cambium-Canopy-LPULCIR = 1 Motorola-Canopy-LPULCIR = 1 Wed Aug 5 10:31:18 2020: DEBUG: Packet dump: *** Received from 127.0.0.1 port 1645 .... Code: Access-Accept Identifier: 156 Authentic: <15><214><217>><207><22><138>A<134><7><245><198><186><217><205><233> Attributes: Motorola-Canopy-LPULCIR = 1 Motorola-Canopy-LPULCIR = 1 OK regards Hugh > On 5 Aug 2020, at 10:50, Brandon Shiers <[email protected]> wrote: > > 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. > > Get Outlook for iOS > > From: radiator <[email protected]> on behalf of Hugh > Irvine <[email protected]> > Sent: Tuesday, August 4, 2020 6:41 PM > To: Heikki Vatiainen > Cc: [email protected] > Subject: Re: [RADIATOR] Issues with VSA > > > 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 -- 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
