Alan DeKok wrote: >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, thanks! Then I'll use that as my working basis. > 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? I was never trying to imply that - all I was trying to do was find an explanation for behaviour that didn't make sense to me. Your answer above stating that this is the way things are, works fine for me. Thanks & Regards, J. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
