I believe there is a bug in the handling of the Tunnel-Password attribue.
Explanation if for 1.15, but at first glance it still seems there in 2.16.1.
My setup in when user Radiator as a proxy :
- it forwards the Access-Request to a remote server
- on positive answer it adds the Tunnel-Password to the reply before
sending it back to the original server.
In encode_tunnel_password, the password is encrypted using data from
$p->{Client}. In the above situation it just happens that $p->{Client}
is an empty hash.
Going a little bit up in the stack, we're now in function
Radius::handle_radius_socket_read, and particularly here :
# sp is the packet we forwarded to the remote radius
# op is the original request we received triggered this whole
# thing off
my ($op, $sp, $rp) = @$ref;
if (defined $sp)
{
...
If I'm understanding well the code, $op->{Client} does contain data from
the original packet, ie this includes the Secret I need for encoding the
Tunnel-Password field. $p is the reply I received from my own server behind
and $rp is the response I am preparing.
adjustReply will be called with $p and $rp, but not $op. This means that
the adjustReply function will not have the values from the $op->{Client}
hash, but just empty structues instead.
Is my analysis correct ? If yes can we consider this is a bug ?
As a more generic question regarding this particular field, let's now
assume that the Tunnel-Password field is not set by the intermediate
proxy, but by the one at the end of the cycle. Will Proxy Radiator
decode this password and encode it again with the new secret, before
sending the reply, or will this just be sent transparently (if transparently
then the answer is perhaps just Tunnel-Password shall only be set by the
Radius servers facing the NAS ?).
--
Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Oleane
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
