Hi, For some reason the module returns noop ;-( I tried the following: I created new 'files' instance: files post_proxy_files { usersfile = ${confdir}/post-proxy-users acctusersfile = ${confdir}/post-proxy-users auth_usersfile = ${confdir}/post-proxy-users postproxy_usersfile = ${confdir}/post-proxy-users postauth_usersfile = ${confdir}/post-proxy-users } (yes it's an overkill, I just tried to figure out which file is the one to be read during that phase) The post-proxy-users has the following syntax: DEFAULT NAS-IP-Address == '10.119.255.244' Cisco-AVpair += "ip:dns-servers=x.y.129.67 x.y.129.68", Framed-Pool += "wc-1", Huawei-Primary-DNS += "x.y.129.67", Huawei-Secondary-DNS += "x.y.129.68" (which is the same as the 'auth' section, without the Proxy-To-Realm statement). and the post-proxy section: post-proxy { post_proxy_files $INCLUDE post-proxy.conf attr_filter.post-proxy # reply_log } During the debug I get the following: Going to the next request rad_recv: Access-Accept packet from host 127.0.0.1 port 1815, id=175, length=57 IHUG-Speed-Down = "64" IHUG-Speed-Up = "64" Framed-Protocol = PPP Service-Type = Framed-User Proxy-State = 0x323339 +- entering group post-proxy ++[post_proxy_files] returns noop Which suggests that the module didn't find anything worth dwelling on. So I made a small experiment - replaced the entry in the users file with: DEFAULT Framed-Protocol == PPP Cisco-AVpair += "ip:dns-servers=x.y.129.67 x.y.129.68", Framed-Pool += "ihug-wc-1", Huawei-Primary-DNS += "x.y.129.67", Huawei-Secondary-DNS += "x.y.129.68" (to match the reply from the home server) and I got exactly what I wanted: +- entering group post-proxy postproxy_users: Matched entry DEFAULT at line 4 ++[post_proxy_files] returns ok and it returned the whole answer. Reading rlm_files.c I found the following: static int file_postproxy(void *instance, REQUEST *request) { struct file_instance *inst = instance; return file_common(inst, request, "postproxy_users", inst->postproxy_users, request->proxy_reply->vps, &request->reply->vps); } does that mean that in fact looks for the match only in the 'proxy-reply' packet? I guess the easiest way to fix this is to use unlang to update the reply packet based on information from either control or request attributes. kind regards Pshem