Missing NAS-Port in Access request with respect to RFC 2865
Hello Freeradius-users,
From what I see in the mailing list archives several freeradius users have historically run into trouble with Access-Request information sent by NASes and particularly the lack of the NAS-Port attribute. I've run into it quite often recently and was wondering if I may have found a way to solve it. The workaround I currently employ is to configure acct_users to let the access request from the NAS in question through anyway but it's a workaround. If possible I'd like to find the *correct* solution.... :-)
The RFC 2865 http://www.freeradius.org/rfc/rfc2865.html#NAS-Port states that: "Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request <http://www.freeradius.org/rfc/rfc2865.html#Access-Request> packet, if the NAS differentiates among its ports."
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).
if (!port_seen) { 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? I'm thinking something along the lines of changing line 404 of rlm_radutmp.c to: if (!port_seen && !nas_port_type) { I'll apologise in advance if my all too rusty programming skills are making me misunderstand the situation entirely... Best Regards, Johannes Ramm-Ericson ----------------------------------------------------------- The information in this e-mail, and attachment(s) thereto, is strictly confidential and may be legally privileged. It is intended solely for the named recipient(s), and access to this e-mail, or any attachment(s) thereto, by anyone else is unauthorized. Violations hereof may result in legal actions. Any attachment(s) to this e-mail has been checked for viruses, but please rely on your own virus-checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications in the matter concerned. If you do not consent to us storing your name and address for above stated purpose, please notify the sender promptly. Also, if you are not the intended recipient please inform the sender by replying to this transmission, and delete the e-mail, its attachment(s), and any copies of it without, disclosing it.
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.
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
Ranner, Frank MR wrote:
I've noticed that NAS-Port is sometimes not sent, particularly in accounting requests. This caused the Accounting request to essentially be discarded.
Uh... no. The server doesn't work like that.
What I figured was to use the source udp port as a pseudo nas-port.
This won't work.
I did add some code to populate the Packet-Src-Port item,
You don't need to do that. The attribute exists if you reference it as %{Packet-Src-Port}.
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.
Well, yes. NAS-Port is for *dial-in* port, or *switch* port. It is *not* for telnet sessions. You're trying to add NAS-Port to sessions that don't need it, don't use it, and where it doesn't make sense. Alan DeKok.
participants (3)
-
Alan DeKok -
Ramm-Ericson, Johannes -
Ranner, Frank MR