Andriy Gapon <[EMAIL PROTECTED]> wrote: > Errors reading dictionary: dict_init: > /usr/local/local/dictionary.mine[3]: dict_addattr: Duplicate attribute > name Digest-Response > Errors reading radiusd.conf > > Shouldn't I be able to override name->number mapping for attributes ?
Yes, so long as the only thing different is the name. ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 ipaddr is OK. ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 string is not OK. And why are you trying to re-define Digest-Response? It's already defined in the dictionaries. Can you describe what you think you're doing, or what result you expect to gain from this? > On a related note - is it a good idea in general to have digest > authentication stuff defined in main dictionary file and > dictionary.freeradius.internal ? Please *read* the attribute definitions. The definitions in dictionary are RADIUS attributes that go over the wire. The ones in dictionary.freeradius.internal are not. > Especially given that those definitions are based on the very old > and expired draft and are very unlikely to become standard. Standards matter less thyan interoperability. There are many systems deployed with the current digest attributes. Changing them now is not an option. > I think that those definitions should be clearly separated into > their own dictionary Once a standard is published for digest, the attributes in that standard will be placed in their own dictionary. > and they should also somehow be marked as based on the > draft-sterman-aaa-sip-00.txt The ones in "dictionary" are marked as being based on that draft. The ones in dictionary.freeradius.internal are not marked as being based on that draft, because they are not. > and conflicting with the subsequent drafts, including the latest one > (draft-ietf-radext-digest-auth-06.txt). Which came out recently. The FreeRADIUS dictionaries have had the existing definitions for almost four years. Also, the new draft isn't standardized. And the new draft doesn't have any implementations that I'm aware of. And the new draft doesn't conflict with the internal FreeRADIUS attributes, because FreeRADIUS doesn't implement the new draft. If you want to go edit your dictionaries to support a draft which isn't implemented in FreeRADIUS, go ahead. But I can't see why anyone would want to do that. Once the draft is standardized, we'll update the dictionaries and implement the protocol. Until then, editing the dictionaries is a complete waste of time. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
