A.3 Proposed Solution

(This message will disappear, once this node revised.)

Processing of incoming requests is controlled by request-processing program. Request-processing program is a list-like structure, consisting of instructions.

A.3.1 Request-processing Instruction

Request-processing program consists of instructions. There are seven basic instruction types:

grad_instr_conditional_t

This instruction marks a branch point within the program.

grad_instr_call_t

Represents a call of a subprogram

grad_instr_action_t

Invokes a Rewrite function

grad_instr_proxy_t

Proxies a request to the remote server

grad_instr_forward_t

Forwards a request to the remote server

grad_instr_reply_t

Replies back to the requesting NAS.

Consequently, an instruction is defined as a union of the above node types:

Instruction: grad_instr_t

enum grad_instr_type { grad_instr_conditional, grad_instr_call, grad_instr_return, grad_instr_action, grad_instr_reply, grad_instr_proxy, grad_instr_forward }; typedef struct grad_instr grad_instr_t; struct grad_instr { enum grad_instr_type type; grad_instr_t *next; union { grad_instr_conditional_t cond; grad_instr_call_t call; grad_instr_action_t action; grad_instr_reply_t reply; grad_instr_proxy_t proxy; grad_instr_forward_t forward; } v; };

Type member contains type of the instruction. The evaluator uses type to determine which part of union v, holds instruction-specific data.

Next points to the next instruction. The evaluator will go to this instruction unless the present one changes the control flow.

Finally, v contains instruction-specific data. These will be discussed in the following subsections.

A.3.2 grad_instr_conditional

(This message will disappear, once this node revised.)

Instruction: grad_instr_conditional_t cond iftrue iffalse

struct grad_instr_conditional { grad_entry_point_t cond; /* Entry point to the compiled Rewrite condition */ grad_instr_t *iftrue; /* Points to the ``true'' branch */ grad_instr_t *iffalse; /* Points to the ``false'' branch */ }; typedef struct grad_instr_conditional grad_instr_conditional_t;

Instructions of type grad_instr_conditional_t indicate branching. Upon encountering an grad_instr_conditional_t, the engine executes a Rewrite expression pointed to by cond. If the expression evaluates to true, execution branches to instruction iftrue. Otherwise, if iffalse is not NULL, execution branches to that instruction. Otherwise, the control flow passes to grad_instr_t.next, as described in the previous section.

RPL representation

RPL defun: COND expr if-true [if-false]

expr

Textual representation of Rewrite conditional expression or its entry point.

if-true

RPL expression executed if expr evaluates to t.

if-true

Optional RPL expression that is executed if expr evaluates to nil.

Example

COND with two arguments:

(COND "%[User-Name] ~= \"test-.*\""
      (REPLY Access-Reject ("Reply-Message" . "Test accounts disabled")))
     

COND with three arguments:

(COND "%[Hint] == "PPP" && authorize(PAM)"
      (REPLY Access-Accept
             ("Service-Type" . "Framed-User")
             ("Framed-Protocol" . "PPP"))
      (REPLY Access-Reject
             ("Reply-Message" . "Access Denied")))
     

A.3.3 grad_instr_call

(This message will disappear, once this node revised.)

Instruction: grad_instr_call_t entry

struct grad_instr_call { grad_instr_t *entry; }; typedef struct grad_instr_call grad_instr_call_t;

Instructions of type grad_instr_call instruct the engine to call the given subprogram. The engine pushes the current instruction to the return point stack and branches to instruction entry. Execution of the subprogram ends when the engine encounters an instruction of one of the following types: grad_instr_return, grad_instr_reply or grad_instr_proxy.

If grad_instr_return is encountered, the engine pops the instruction from the top of the return point stack and makes it current instruction, then it branches to the next node.

If grad_instr_reply or grad_instr_proxy is encountered, the engine, after executing corresponding actions, finishes executing the program.

RPL representation

RPL defun: CALL list

RPL defun: CALL defun-name

In the first form, the argument list is the RPL subprogram to be executed.

In the second form defun-name is a name of the RPL subprogram defined by defun.

Examples

First form:

(CALL (ACTION "myfun(%[User-Name])")
      (REPLY Access-Reject
             ("Reply-Message" . "Access Denied")))

Second form:

(CALL process_users)

A.3.4 grad_instr_return

(This message will disappear, once this node revised.)

An instruction of type grad_instr_return indicates a return point from the subprogram. If encountered in a subprogram (i.e. a program entered by grad_instr_call node), it indicates return to the calling subprogram (see the previous subsection). Otherwise, if grad_instr_return is encountered within the main trunk, it ends evaluating of the program.

Instructions of this type have no data associated with them in union v.

RPL representation

RPL defun: RETURN

Examples

(RETURN)

A.3.5 grad_instr_action

(This message will disappear, once this node revised.)

Instruction: grad_instr_reply_t expr

struct grad_instr_action { grad_entry_point_t expr; /* Entry point to the compiled Rewrite expression */ }; typedef struct grad_instr_action grad_instr_reply_t;

The machine executes a Rewrite expression with entry point expr. Any return value from the expression is ignored.

RPL representation

RPL defun: ACTION expr

RPL defun: ACTION entry-point

Examples

(ACTION "%[NAS-IP-Address] = request_source_ip()")

A.3.6 grad_instr_reply

(This message will disappear, once this node revised.)

Instruction: grad_instr_reply_t return_code

struct grad_instr_reply { u_char reply_code; /* Radius request code */ }; typedef struct grad_instr_reply grad_instr_reply_t;

grad_instr_reply instructs radiusd to send to the requesting NAS a reply with code reply_code. Any reply pairs collected while executing the program are attached to the reply.

After executing grad_instr_reply instruction, the engine stops executing of the program.

Any execution path will usually end with this instruction.

RPL representation

RPL defun: REPLY reply-code [attr-list]

Arguments:

reply-code

Radius reply code.

attr-list

List of A/V pairs to be added to the reply. Each A/V pair is represented as a cons: (name-or-number . value).

Example

(REPLY Access-Accept
       ("Service-Type" . "Framed-User")
       ("Framed-Protocol" . "PPP"))

A.3.7 grad_instr_proxy

(This message will disappear, once this node revised.)

Instruction: grad_instr_proxy_t realm

struct grad_instr_proxy { grad_realm_t realm; }; typedef struct grad_instr_proxy grad_instr_proxy_t;

This instruction tells radius to proxy the request to the server defined in realm. In other words, the engine executes proxy_send. Further processing of the program is stopped.

RPL representation

RPL defun: PROXY realm-name

Realm-name is name of the realm as defined in ‘raddb/realms’.

Examples

.

A.3.8 grad_instr_forward

(This message will disappear, once this node revised.)

Instruction: grad_instr_forward_t server_list

struct grad_instr_forward { grad_list_t server_list; }; typedef struct grad_instr_forward grad_instr_forward_t;

This node forwards the request to each servers from server_list. Forwarding differs from proxying in that the requests are sent to the remote servers and processed locally. The remote server is not expected to reply. See section forwarding, for more information on this subject.

In contrast to grad_instr_proxy, this instruction type does not cause the execution to stop.

Elements of server_list are of type grad_server_t.

Currently forwarding is performed by forward_request function (‘forward.c’), which could be used with little modifications. Namely, it will be rewritten to get server list as argument, instead of using static variable forward_list. Consequently, the functions responsible for creating and initializing this static variable will disappear along with the variable itself. .

A.3.9 RPL representation

RPL defun: FORWARD server-list

This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.