interesting issue with dictionary file in FR 3.x GIT
hi, we have an interesting issue with dictionaries in 3.x 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 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 ...so the dictionary file parsing is wrong/absent alan
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.
On 30/05/12 10:30, Alan DeKok wrote:
The code in 3.0 has been changed to print out generic names for unknown attributes. This is different from 2.x.
For any specific reason? I don't care one way or the other, just curious.
If you have third-party tools which read the detail files, fix them to use libfreeradius-radius. That will parse the attributes correctly.
One thing worth bearing in mind is that many (most?) detail parsers I've seen are not written in "C". This is perfectly reasonable given the use-case, and calling into libfreeradius-radius from those tools is likely prohibitively complex. It's probably not an issue in practice of course, since these are *unknown* attributes; I suspect if people care about them, they'll be defined in dictionaries.
Phil Mayers wrote:
For any specific reason? I don't care one way or the other, just curious.
The extended attributes. They're fairly weird. It is useful to have just *one* way to parse unknown attributes. The new OID format is general, simple, and works.
If you have third-party tools which read the detail files, fix them to use libfreeradius-radius. That will parse the attributes correctly.
One thing worth bearing in mind is that many (most?) detail parsers I've seen are not written in "C". This is perfectly reasonable given the use-case, and calling into libfreeradius-radius from those tools is likely prohibitively complex.
Well.... they're going to have to be updated to understand the new extended attributes.
It's probably not an issue in practice of course, since these are *unknown* attributes; I suspect if people care about them, they'll be defined in dictionaries.
Yup. Alan DeKok.
participants (3)
-
alan buxey -
Alan DeKok -
Phil Mayers