proxy problems with 2.0.5

Pshem Kowalczyk pshem.k at
Tue Jun 10 02:02:23 CEST 2008


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 == ''
        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 {
                $INCLUDE post-proxy.conf
        #       reply_log

During the debug I get the following:

Going to the next request
rad_recv: Access-Accept packet from host 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",
                           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

kind regards

More information about the Freeradius-Users mailing list