All, First, thank you for an excellent server. Within a few hours we went from google-ing for a radius server to having a proxy up which does (almost) everything we needed to make a third party device/server learn many cool new tricks. Unfortunately last night I had to spend 3 hours (maybe "only" 3 hours, attesting to high code quality) in trying to figure out why Access-Reject messages were loosing all but the Reply-Message attribute. Eventually I did find, first a hint on the mailing lists, then the RFC, and then finally after quite a bit of digging, the code in util.c : case PW_AUTHENTICATION_REJECT: pairmove2(&vps, &(packet->vps), PW_EAP_MESSAGE); pairmove2(&vps, &(packet->vps), PW_MESSAGE_AUTHENTICATOR); pairmove2(&vps, &(packet->vps), PW_REPLY_MESSAGE); break; I would like to suggest at least two small changes to make freeradius an even better tool than it already is. The first is really simple and would take practically no work at all: can we please have a log message here that notifies the user of this operation when running with -X? This would have saved me most of the time I've spent digging through mailing lists and the rlm_attr_filter code, and allowed me to quickly find the above culprit. This is actually quite necessary, since any "detail" logs that can be inserted on the proxy reply path happily show all attributes - the attributes magically disappear right before packet is sent. The second request is also trivial to implement: make the above code configurable/optional. Yes, there is a great deal of strength and respect in supporting the RFC to the dot - and without a doubt, that should be the default out-of-the-box configuration. But not all devices are created equal - and in my case, as I'm sure in some others, useful information is passed in the Access-Reject message in attributes other than Reply-Message. Obviously this is not compliant - but all the devices I have are quite happy accepting those "extra" arguments, and a third party server is certainly very happy to send them. Making this code "optional" with a config file switch saves me from hacking the sources. Code change can be achieved simply by moving up case PW_AUTHENTICATION_REJECT: above the default: case and wrapping the 4 line body (including break;) inside of an if statement, so this change is also quite triviail. The third "request" or "option" perhaps, is a bit more complex. I would propose that the above code is actually a hack to comply with RFC, and that the appropriate mechanism of accomplishing this effect is through an appropriate set of attribute filters (enabled by default). This would require extending the attr_filters module to consider the request/response type being filtered. The default configuration can point out the RFC in the comments and filter out everything with the three exceptions. This of course allows for maximal flexibility, while still respecting the standard in the default configuration. I think this one is quite a bit more work, so I do not put too many hopes into it, but I figured I would throw it out on the table. Again, thanks for a great server. The above "hickup" is hardly worth mentioning when compared to the overall experience we've had in setting up the proxy and getting it to do what we want.