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