interesting issue with dictionary file in FR 3.x GIT

[Alan DeKok]

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.