Missing NAS-Port in Access request with respect to RFC 2865

Alan DeKok aland at deployingradius.com
Fri Apr 4 08:39:05 CEST 2008


Ramm-Ericson, Johannes wrote:
> OK. However, access requests from that particular NAS are in effect not
> processed the way I expect because of the lacking NAS-Port which still
> leaves me with a problem I need to understand and fix.

  There is likely nothing that you can do.  This is the reality of
working with different RADIUS implementations and administrators.

> OK. But what I was trying to say was that I think the if statement in
> rlm_radutmp is not correctly interpreting the RFC. From my understanding
> the RFC says that "either NAS-Port or NAS-Port-Type or both" must be
> present. However:

  Again, the radutmp module needs a NAS-Port for it's own internal
purposes.  This has *nothing* to do with the RFC requirements.

  Did you understand my analogy with the PAP module?

> Just to clarify; I may very well be wrong about all this but I have a
> workaround that I think is just that: a workaround, rather than a
> correct solution. My hope is that either someone on the mailinglist can
> explain why I'm getting it all wrong or that I actually have found a bug
> and that it in that case hopefully can be squashed.

  It is not a bug.  It is perfectly valid for different modules in the
server to do different things with a RADIUS packet.  Does that make
sense to you?

  If you would have it your way, *every* module in the server would
enforce *all* of the RFC requirements.  This is nonsense.  You would not
require the PAP module to accept CHAP, MS-CHAP, etc.  So why make the
radutmp module understand NAS-Port-Type?

  If you think that you need to run the "radutmp" module *always* for
*every* accounting request, then you need to come to a realization: the
server doesn't work that way.  The "radutmp" module runs for *certain*
requests that match *certain* criteria.  Some requests which meet RFC
requirements cause the radutmp module to run.  Other requests which
*also* meet the RFC requirements cause the radutmp module to *not* run.

  Just like the PAP module.  Just like the CHAP module.  Just like the
MS-CHAP, EAP, Digest, or many other modules.

  The radutmp module needs NAS-Port to operate.  It cannot use
NAS-Port-Type.  If you do not see a NAS-Port in the request, then the
radutmp module will do nothing.  Making the radutmp module look for
NAS-Port-Type is wrong.

  I also note that in all of this you haven't made it clear what your
requirements are.  If you want a "radumtp" entry for all users, then
your requirements are wrong.  Those requirements CANNOT be met using
standard, RFC-compliant, RADIUS packets.

  Alan DeKok.



More information about the Freeradius-Users mailing list