I have a FreeRADIUS server 2.2.0 on a Linux box A, and a RADIUS client on a different Linux box B. The client in B has been constructed using as a basis one of the examples distributed with the FreeRADIUS 1.1.6 client code. The client uses the RADIUS library distributed with this code. Things seem to work fine, in that I can carry out authentications on A on behalf of B all right. I am having problems when trying to decode on B a vendor-specific attribute sent by A. Initially I had my users defined in /etc/freeradius/users in A along the following lines: user1 User-Password != "User1Password" user1 Cleartext-Password := "User1Password" Reply-Message = "Authentication successful." With this, the string associated with the Reply-Message attribute is sent by the server only when the authentication succeeds. On the FreeRADIUS 1.1.6 client the rc_send_server() function detects that the response payload contains more information than just the authentication diagnostic, and proceeds to decoding it by invoking rc_avpair_gen(), which in turn recognizes the Reply-Message attribute identifier and the associated string value without any problems. 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." 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 rc_avpair_gen() correctly identifies that this is a vendor-specified attribute (byte 0x1a) and then extracts the vendor ID itself (bytes 0x73 0xf8, or 29688 in decimal.) After verifying that this is a vendor ID that it knows about, rc_avpair_gen() invokes itself recursively on the input data offset by 7 bytes (i.e. starting at the 0x01 byte that follows the 0xf8 byte) and with the 29688 vendor ID already retrieved. rc_avpair_gen() then executes the following line: attribute = ptr[0] | (vendorpec << 16) where ptr[0] is 0x01, and vendorpec is 0x73f8. After this, attribute takes the value 0x73f80001. 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: DICT_ATTR *rc_dict_getattr (const rc_handle *rh, int attribute) { DICT_ATTR *attr; attr = rh->dictionary_attributes; while (attr != NULL) { if (attr->value == attribute) { return attr; } attr = attr->next; } return NULL; } Now the attr entry for the matching attribute is $53 = {name = "Vendor-Attr", '\000' <repeats 19 times>, value = 1, type = 0, next = 0x804bc90} as obtained with gdb. 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. Notice that fudging things with gdb so that the value of attribute is set to what it should be (1) also does not work, for in that case the attribute is identified as a User-Name, instead of the vendor-specific attribute Vendor-Attr. 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?