Problems decoding a vendor-specified attribute on the client side

[Alan DeKok]

JCA wrote:
> I would like to be able to use a vendor-specified attribute, rather
> than Reply-Message, and to that end I added the following entry to the
> dictionary files in both client and server:
> 
>        VENDOR          MyVendorID    29688
> 
>        BEGIN-VENDOR    MyVendorID
>        ATTRIBUTE            Vendor-Attr  1    string
>        END-VENDOR      MyVendorID
> 
> (the vendor ID used here is bogus.)  I also changed my users on the
> server as follows:
> 
>      user1      User-Password != "User1Password"
>      user1      Cleartext-Password := "User1Password"
>           Vendor-Attr = "Authentication successful."

  I'd give it a better name than that... but OK.

> After launching the server on A again, and attempting an
> authentication from B, debugging the client on B reveals that the
> server is indeed sending the Vendor-Attr attribute with the value
> specified in the users file. The rc_avpair_gen() function in the
> client code on B detects a vendor-specified attribute, and after
> properly identifying it as MyVendorID it attempts to decode the
> attribute that follows by recursively invoking itself. In more detail:
> 
> The first few bytes of the data received from the server is
> 
>       0x1a    0x1b    0x00    0x00    0x73    0xf8    0x01    0x15

  That's how RADIUS works.

  You need to add the vendor dictionary on the client side, too.

>       The code then proceeds to invoking rc_dict_getattr() in order to
> get the attribute, using as arguments the dictionary data previously
> loaded when launching the client, plus the value of the attribute
> variable obtained above. rc_dict_getattr() will just loop over all
> entries in the dictionary data, trying to find a match. This is a very
> simple function:

  Yes... there's no need to include the code here.  We *do* have access
to it.

>        The comparison in the loop above will not succeed, because
> attr->value is 1, whereas attribute is 0x73f80001. Therefore no match
> will be found, and rc_dict_getattr() will return a NULL pointer, thus
> causing rc_avpair_gen() to generate an error message as follows:
> 
>         received unknown VSA attribute 1, vendor 29688 of length xx
> 
> where xx is the length of the "Authentication successful." string.
>
>         Thus, it would seem that the data was received correctly, but
> can't somehow be decoded.

  Yes.  You need to add the dictionary on the client side, too.

  The main FreeRADIUS library handles this properly, by the way.  It
allows you to reference attributes which don't have any dictionaries.

>         Anybody know what is going on here? I would be tempted to say
> that the rc_dict_getattr() implementation is wrong, but I find it
> difficult to believe that it is THAT wrong - this wouldn't be just a
> bug, but a huge implementation error. Therefore, I must be doing
> something wrong myself instead. But, what? How do I define my simple
> vendor-specific attribute so that rc_get_attr() can identify and
> decode it correctly?

  Use a dictionary.

  Or, update the code so that it still creates AVPairs, even if it
doesn't have a dictionary entry.  This is what the FreeRADIUS server does.

  Alan DeKok.