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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
