[RADIATOR] reply bug

[Heikki Vatiainen]

On 07/08/2013 06:30 PM, Alexander Hartmaier wrote:

> it seems Radiator has a bug when replying to Radius requests on hosts
> that have more than one IPv4 address on an interface.
> For example with the default binding of 0.0.0.0 and a Linux server with
> the following ip addresses (ip addr output):
> 
>     inet 1.2.3.8/24 brd 1.2.3.255 scope global eth0
>     inet 1.2.3.9/24 brd 1.2.3.255 scope global secondary eth0:0
> 
> When sending a Radius request to 1.2.3.9 the reply is sent from 1.2.3.8.

Unfortunately this is actually a feature of how UDP wildcard sockets
work. There is no standard way to find out the destination address of
the request. Also, there is no standard way to set the source address of
the reply.

If there is such a way, it might have become available with the socket
API IPv6 enhancements. But still there's the problem of the currently in
use implementations: would they support this. For example, the recently
discussed IPV6_V6ONLY setsockopt is available with Perl 5.16.0 and later.

> Binding Radiator only to 1.2.3.9 works around the problem.

Yes. The problem can be worked around by binding to individual
addresses. Making this automatic is once again problematic: there is no
standard way to enumerate the interfaces to find out all addresses the
system has.

However, if there are supported ways to do all or some of the above, I
would be interested to hear more.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.