Minor inconsistency in FreeRadius 1.0.4 dictionary file
Hi, It seems that there is a minor inconsistency in the dictionary file (which is also used by Ethereal for handling Radius attributes). The inconsistency shows up here:
ATTRIBUTE Callback-Number 19 string ATTRIBUTE Callback-Id 20 string ATTRIBUTE Framed-Route 22 string ATTRIBUTE Framed-IPX-Network 23 ipaddr ATTRIBUTE State 24 octets ATTRIBUTE Class 25 octets
So, Callback-Number and Callback-Id are treated as strings, wwhile State and Class are treated as octets ... However, RFC2865 says, for Callback-Number and Callback-Id: String The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification However, State and Class also have exactly the same description, so why does the FreeRadius dictionary file code them differently? The consequence of this is that Ethereal displays these attributes differently, when the spec says they should be treated the same. Regards ------- Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Richard Sharpe <rsharpe@richardsharpe.com> wrote:
However, State and Class also have exactly the same description, so why does the FreeRadius dictionary file code them differently?
Practical issues. :) Callback-Number and Callback-Id are pretty much always ASCII strings in practice. Class is often an ASCII string, but sometimes not. State is almost always non-ASCII data. The types in the dictionaries are a result of a trade-off between going with what the RFC's say, and going with what happens in the real world.
The consequence of this is that Ethereal displays these attributes differently, when the spec says they should be treated the same.
The spec also says that a whole host of theings SHOULD or MUST happen with RADIUS packets. Not all of them happen in real-world implementations. Alan DeKok.
participants (2)
-
Alan DeKok -
Richard Sharpe