RE: Re: Missing NAS-Port in Access request with respect to RFC 2865
Alan DeKok wrote:
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.
Fair enough, from my usage perspective the server and module are one unit. They are however separate entities and I could have been more explicit in my description.
The request is *not* denied if there is no NAS-Port.
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. The NAS admins on the other end refuse to forward the NAS-Port because their experience with other Radius servers has never made the presence of NAS-Port a requirement earlier. I suspect that the terminology of the RFC actually confirms their point of view.
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 apologise; I should rather have said that the request is not being processed further as I am hoping it would.
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.
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: if (!port_seen) { looks to be saying that NAS-Port *must* always be present, which isn't quite the same thing. 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.
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".
Absolutely. I should have put more effort into explaining what I'm thinking is wrong. Cheers, J.
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.
participants (2)
-
Alan DeKok -
Ramm-Ericson, Johannes