Hi Guys Is there any reason why "dictionary.digest" exists but is not included (It should actually be called dictionary.rfc4590) and the attributes are instead declared in "dictionary.freeradius.internal"? I have changed dictionary.digest to dictionary.rfc4590 in the 1.1.x branch but have not included it yet. Can we clean this stuff up? I am trying to get FreeRADIUS to the point where it works with SIP servers (SER etc) out of the box. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Is there any reason why "dictionary.digest" exists but is not included (It should actually be called dictionary.rfc4590) and the attributes are instead declared in "dictionary.freeradius.internal"?
dictionary.digest is a hack (defines sub-attributes). It shouldn't exist.
I have changed dictionary.digest to dictionary.rfc4590 in the 1.1.x branch but
Uh, oh. That's not good. The dictionary.digest file is *not* the same as what's in RFC 4590.
have not included it yet. Can we clean this stuff up? I am trying to get FreeRADIUS to the point where it works with SIP servers (SER etc) out of the box.
No one has implemented RFC 4590 yet. Plus, the RFC is wrong, as the attribute numbers are incorrect, and the final table of what's allowed where is incorrect. It will be re-issued in a month or two. Please don't do *anything* with RFC 4590. It's existence is a figment of your imagination. Once the updated RFC comes out, we'll use that. The hardest part about the digest RFC is that the attribute numbers it has will conflict with stupid Ascend pseudo-VSA's. We've got to support both, so there's some magic required in src/lib/radius.c Again, RFC 4590 doesn't exist. Wait a few months for a fixed version. Don't implement ANYTHING based on RFC 4590. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue 14 Nov 2006 03:25, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Is there any reason why "dictionary.digest" exists but is not included (It should actually be called dictionary.rfc4590) and the attributes are instead declared in "dictionary.freeradius.internal"?
dictionary.digest is a hack (defines sub-attributes). It shouldn't exist.
I have changed dictionary.digest to dictionary.rfc4590 in the 1.1.x branch but
Uh, oh. That's not good. The dictionary.digest file is *not* the same as what's in RFC 4590.
OK. It is NOT included yet...
have not included it yet. Can we clean this stuff up? I am trying to get FreeRADIUS to the point where it works with SIP servers (SER etc) out of the box.
No one has implemented RFC 4590 yet. Plus, the RFC is wrong, as the attribute numbers are incorrect, and the final table of what's allowed where is incorrect. It will be re-issued in a month or two.
Ahh.. That I didn't know.
Please don't do *anything* with RFC 4590. It's existence is a figment of your imagination. Once the updated RFC comes out, we'll use that.
http://www.ietf.org/rfc/rfc4590.txt ???
The hardest part about the digest RFC is that the attribute numbers it has will conflict with stupid Ascend pseudo-VSA's. We've got to support both, so there's some magic required in src/lib/radius.c
Again, RFC 4590 doesn't exist. Wait a few months for a fixed version. Don't implement ANYTHING based on RFC 4590.
OK. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Hi Peter, Alan, Alexander Schrab and I have been working on a patch that allows to have both draft-sterman's and RFC 4590's attributes handled by FreeRADIUS. http://bugs.freeradius.org/show_bug.cgi?id=391 It is true that Ascend attributes conflict with the newly defined RFC 4590 attributes, so that modifications are needed. However, I have been using this for more than a month along with an OpenSER box (pre-RFC 4590) without problem. And and believe Alex too. Maybe we can take the patch in bug #391 as a basis for the future RFC 4590 implementation? Philippe
Peter Nixon <listuser@peternixon.net> wrote:
Please don't do *anything* with RFC 4590. It's existence is a figment of your imagination. Once the updated RFC comes out, we'll use that.
<g> The IETF RADIUS group decided last week that RFC 4590 was a lost cause, and would be re-issued with corrected numbers. In the mean time, implementations of RFC 4590 are based at least in part on guesses and inference, rather than a standard. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue 14 Nov 2006 17:24, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Please don't do *anything* with RFC 4590. It's existence is a figment of your imagination. Once the updated RFC comes out, we'll use that.
<g> The IETF RADIUS group decided last week that RFC 4590 was a lost cause, and would be re-issued with corrected numbers. In the mean time, implementations of RFC 4590 are based at least in part on guesses and inference, rather than a standard.
Oh Good. I thought I was going insane there for a minute... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (3)
-
Alan DeKok -
Peter Nixon -
Philippe Sultan