Missing NAS-Port in Access request with respect to RFC 2865 [SEC=UNCLASSIFIED]

[Ranner, Frank MR]

UNCLASSIFIED

> -----Original Message-----
> From: 
> freeradius-users-bounces+frank.ranner=defence.gov.au at lists.fre
eradius.org [mailto:freeradius-users->
bounces+frank.ranner=defence.gov.au at lists.freeradius.org] On 
> Behalf Of Alan DeKok
> Sent: Thursday, 3 April 2008 20:22
> To: FreeRadius users mailing list
> Subject: Re: Missing NAS-Port in Access request with respect to RFC 
> 2865
> 
> Ramm-Ericson, Johannes wrote:
> >>From what I understand the current Freeradius code
> interprets the RFC
> > statement so that if the NAS-Port attribute is not sent then the 
> > access request is not processed and subsequently denied (in 
> > rlm_radutmp.c - line 404).
> 
>   No.
> 
>   The *radutmp* module requires the NAS port for it's proper 
> operation.
>  The *server* does not.
> 
>   The request is *not* denied if there is no NAS-Port.
> 
> > However; shouldn't the statement from the RFC be intertpreted such 
> > that if *neither* the NAS-Port or the NAS-Port-Type is set then the 
> > access request should not be processed and subsequently denied?
> 
>   No.  I have no idea why you think the request is being denied.
> 
> > I'm thinking
> > something along the lines of changing line 404 of rlm_radutmp.c to:
> >  
> >    if (!port_seen && !nas_port_type) {
> 
>   No.  The radutmp module needs a NAS-Port to put into the radutmp 
> data structure.  The NAS-Port-Type attribute cannot be used for this 
> purpose.
> 
> > I'll apologise in advance if my all too rusty programming
> skills are
> > making me misunderstand the situation entirely...
> 
>   I think you're confusing "server" with "module".
> 
>   e.g. the PAP module requires a User-Password in the Access-Request.
> The *server* doesn't, because it can hand the request to another 
> module, like CHAP, or MS-CHAP.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> 

I've noticed that NAS-Port is sometimes not sent, particularly in
accounting requests. This caused the 
Accounting request to essentially be discarded. What I figured was to
use the source udp port as a 
pseudo nas-port. In dictionary.freeradius.internal there is an attribute
Packet-Src-Port that seemed to be 
just what I wanted. All I would need is a rule setting NAS-Port :=
Packet-Src-Port (with the appropriate 
Dereferencing syntax) when NAS-port was undefined. Unfortunately, there
was no code in the server that actually
created the Packet-Src-Port pair. This was in FR 1.1.0 - I haven't
checked later versions. I did add some code to 
populate the Packet-Src-Port item, and this did fix the accounting from
with the Nortel switch I was testing. As it
happened, each telnet session to the switch used a different console
port, and the src port number reflected that.

Regards
Frank Ranner
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: EXTNDATT.TXT
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080407/8dfe6179/attachment.ksh>