[RADIATOR] EAP-TTLS missing reply attributes from inner-accept

[Heikki Vatiainen]

On 06/07/2014 12:14 AM, Christopher Chance wrote:

> For some reason the final reply to the device is not getting the full attributes, we send 2 custom attributes for speed
> 
>         Cambium-Canopy-DLMB=10480,
>         Cambium-Canopy-ULMB=2048

Hello Chris,

if you can pass me these, and any other, Cambium attribute definitions
we can add them to Radiator dictionary.

The configuration looks fine. Is AuthBy EngageIP a modified AuthBy SQL?
>         <Handler TunnelledByTTLS=1>
>             # Check EngageIP DB
>             <AuthBy EngageIP>
>                 DBAuth xxxxxxxxxxxxxxxxxxxxxxxxxx
>                 DBSource dbi:ODBC:Database1111
>                 DBUsername sa
>                 DateFormat %Y-%m-%d %H:%M:%S
>                 Timeout 60

You may want to consider adding NoDefault if this is a AuthBy SQL
derivative.

>             </AuthBy>
>         </Handler>

> Debug log is....

Here's the part of debug log where the reply attributes should be
visible for the first time.

> Fri Jun  6 16:34:26 2014: DEBUG: Handling request with Handler 'TunnelledByTTLS=1', Identifier ''
> Fri Jun  6 16:34:26 2014: DEBUG:  Deleting session for 5mbtest, 192.168.125.233,
> Fri Jun  6 16:34:26 2014: DEBUG: Handling with Radius::AuthEngageIP:
> Fri Jun  6 16:34:26 2014: DEBUG: Handling with Radius::AuthEngageIP:
> Fri Jun  6 16:34:26 2014: DEBUG: Query is: 'SET ANSI_NULL_DFLT_ON ON; exec Interface_VircomUsers_Custom_newtech '5mbtest', NULL, NULL, NULL, NULL':

If this SQL statement returns the attributes, you need to place them
into the reply. However, there's nothing in the configuration that does
it, so either your module does it automatically, or the problem is here.

Please see AuthSelect option in the reference manual, in case your
module uses it. If you do, then you would need to define some
AuthColumnDef parameters unless the SQL result matches what the default
AuthSelect returns.

> Fri Jun  6 16:34:26 2014: DEBUG: Radius::AuthEngageIP looks for match with 5mbtest [5mbtest]
> Fri Jun  6 16:34:26 2014: DEBUG: Radius::AuthEngageIP ACCEPT: : 5mbtest [5mbtest]
> Fri Jun  6 16:34:26 2014: DEBUG: AuthBy EngageIP result: ACCEPT,
> Fri Jun  6 16:34:26 2014: DEBUG: Access accepted for 5mbtest
> Fri Jun  6 16:34:26 2014: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
> Code:       Access-Accept
> Identifier: UNDEF
> Authentic:  <188>^<137>H<194><230><195>$]<225><219>X<165> L\
> Attributes:
>         MS-CHAP2-Success = "rS=A176D373C06AF576BC8316879C999568462B6862"

The reply Cambium-Canopy-* reply attributes should be visible here with
the MS-CHAP2-Success attribute. They are then placed in the outer
request when the final Access-Accept is sent.

Since they are not present, I suspect there's some sort of disconnect in
getting the attributes from the SQL statement return values to the reply.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.