alan buxey wrote:
with 2.x we have the following in /etc/raddb/dictionary ...and can see the following in detail logs
VENDOR Cisco-ASA55x0 3076 BEGIN-VENDOR Cisco-ASA55x0 ATTRIBUTE Cisco-ASA55x0-Banner1 15 string ATTRIBUTE Cisco-ASA55x0-Class 25 string ATTRIBUTE Cisco-ASA55x0-Bookmark 71 string ATTRIBUTE Cisco-ASA55x0-Member-Of 145 string ATTRIBUTE Cisco-ASA55x0-IPv6-Pool 218 string ATTRIBUTE Cisco-ASA55x0-URL-1 223 string END-VENDOR Cisco-ASA55x0
Cisco-ASA55x0-Attr-146 = 0x44666661756c4457454356504e47726f7570 Cisco-ASA55x0-Attr-150 = 0x00000002
Note that those attributes are NOT in the above dictionary.
on 3.x we have the same dictionary file...but the detail logs show this:
Attr-26.3076.146 = 0x44666661756c4457454356504e47726f7570 Attr-26.3076.150 = 0x00000002
Because the attributes don't exist. The code in 3.0 has been changed to print out generic names for unknown attributes. This is different from 2.x.
...so the dictionary file parsing is wrong/absent
The dictionary file parsing is correct. The attribute parsers have been updated to read the new format. So writing / reading the detail file still works. If you're worried that the format changed, don't bother. The format isn't intended for people to read. The server and associated tools read / write it just fine. They will also read the old format for backwards compatibility. If you have third-party tools which read the detail files, fix them to use libfreeradius-radius. That will parse the attributes correctly. You can update the dictionaries to add the unknown attributes, and the problem will go away. Or, take a look at src/lib/print.c, vp_print_name(). Hack it to print the vendor name. It shouldn't be hard. If this is a *major* problem, then I can take a look at hacking vp_print_name(). But I'd rather not. Alan DeKok.