[RADIATOR] Issues with VSA

Brandon Shiers brandon.shiers at cerento.com
Wed Aug 5 12:16:51 UTC 2020


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)
brandon.shiers at cerento.com

-----Original Message-----
From: Hugh Irvine 
Sent: Tuesday, August 04, 2020 7:47 PM
To: Brandon Shiers <brandon.shiers at cerento.com>
Cc: Heikki Vatiainen <hvn at open.com.au>; radiator at lists.open.com.au
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 <brandon.shiers at cerento.com> 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 <radiator-bounces at lists.open.com.au> on behalf of Hugh 
> Irvine <hugh at open.com.au>
> Sent: Tuesday, August 4, 2020 6:41 PM
> To: Heikki Vatiainen
> Cc: radiator at lists.open.com.au
> 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 <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.
> 
> _______________________________________________
> 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.



More information about the radiator mailing list