Alternate proxying methods.

[Arran Cudbard-Bell]

>
>   There was an implementation of it in 0.1 or 0.2, but it was removed
> because is caused a great many problems in the server core.
>
>   
I had a feeling it might be that, it seems it would break with the 
rather linear flow of freeradius.
>> I had assumed that it would copy the incoming packet to the realm specified
>> but also continue processing locally. This would really only be of use 
>> for accounting packets.
>>     
>
>   Yes.  The suggestion now is to use "radrelay".  It's more work, but it
> does the same thing.
>   
*looks at man page* yes that'd do it !

Ah but this would send all the accounting data out to the jrs proxies, 
for which jrs might not look on us
too kindly for . Only a relatively small amount of accounting data would 
actually need to go off site...
for users from other institutions using our wireless AP's but 
authenticating back at there home institutions.

The advantage of using a 'replicate-to-realm' like feature is that you 
can filter the data being replicated, and direct it
to the proper home servers.

I was considering setting up an exec instance pointing to a shell script 
which would forward the data via radclient.
>   I *think* in 2.0 we can get radrelay to duplicate the functionality of
> Replicate-To-Realm without too much effort, but I'll have to spend some
> more time looking into it.
>   
Yeah that would be cool, then you could synchronize all your accounting 
data with multiple off/on-site radius servers.
Especially good for people relying on flat files as opposed to SQL 
databases.
>> Yes so the actual function is fine, it's just the terminology. A more 
>> accurate name might be 'Assign-To-Realm', and then once it's been 
>> 'assigned' the internet logic of the realm
>> will decide where it's actually proxied to.
>>     
*internal logic

I swear my spell checker hates me.

Thanks,
Arran