UNCLASSIFIED
-----Original Message----- From: freeradius-users-bounces+frank.ranner=defence.gov.au@lists.fre eradius.org [mailto:freeradius-users-> bounces+frank.ranner=defence.gov.au@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