radrelay integration & other issues
guy at incentre.net
Mon Jul 10 23:14:41 CEST 2006
On Fri, 2006-07-07 at 16:51 -0400, Alan DeKok wrote:
> Guy Fraser <guy at incentre.net> wrote:
> > 1) I had to change proxy.conf to not proxy the packets to
> > the other proxy servers. It might be nice if radrelay could
> > be configurable to disable proxying while importing data to
> > repopulate the database, especially on a live server.
> Ok... if the "read detail code" isn't part of the server, this can
> be done in the CVS head by:
> 1) having a "listen" section with a socket-specific client (localhost)
> 2) have radrelay send data to that socket
> 3) mark the socket as "radrelay only"
> 4) have the socket add a server-side attribute "FreeRADIUS-Data-Source"
> with value "Radrelay". Maing it server-specific means it can't
> go into a packet
> 5) update the proxy code to abandon proxying if that attribute
> is set.
> > 2) The duplicate entry detection did not work while importing
> > data using radrelay. I am using PostGreSQL as a backend so I
> > added a "unique constraint" to the radacct table to block the
> > duplicate entries.
> Hmm... that's bad.
Which part is bad, the "unique constraint" or the duplicate entries?
The unique constraint only stops the insert from working, the update
succeeds, which is what I want when the record already exists. This
is the same way I designed my customized Cistron Radius to work, it
the insert of the record fails try an update, if that fails, log it
as an error and save the query in a cache file for input after
recovery. I have only had a handful of entries end up in the cache
file in over 5 years.
> > The discrepancy was caused by 6 accounting records that had the same
> > Acct-Session-Id but the delay times and Unique-Session-Id were
> > different.
> Ah... the Unique session Id is partly based on Client-IP-Address,
> which is the "radrelay" address, and not the NAS. That's a problem
> which should be fixed.
Most of the radius transactions I use are from redundant proxy
servers. I believe there may be some circumstances where the
duplicates may come from a different proxy server than the one
the original packet came from. Would it help if I removed the
Client-IP-Address from the Unique session ID?
If you think there should be more entropy values, I could possibly
add the Framed-IP-Address or the Calling-Station-Id.
--- Default ---
key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address,
--- No Client IP ---
key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port"
--- With Framed IP ---
key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, Framed-IP-
Actually I think I may have just realized that was probably what I
should have done to solve the problem, I just didn't have time to
work it out after switching to FreeRadius, from my Custom system.
> Maybe rlm_detail should log Client-IP-Address, too, and radrelay
> needs to find a place to put it in the packet.
> Hmm... that restrictions means it's probably better to leave
> radrelay in the server core, as it's easier to play those games there.
> Alan DeKok.
The move went quite smoothly, after taking a month to prepare scripts
to migrate the users, and develop a PHP interface. The interface was
required to allow users to check their time usage and change their
password, as well as allow hierarchal administration of users and
other administrators, for our affiliate organizations. The interface
is far from all I wanted it to be, but provides all the absolutely
necessary functions and allows reports to be downloaded. I have built
some other PHP functions that will allow access to the configuration
files and dictionaries, but that functionality will not be added for
some time to come. So far the code is only good enough for in-house
use, and needs a lot of cleanup and some more auditing before I would
consider providing it to the project. Their is currently a fair bit
of redundant code, and bit kludge, from reusing code originally
developed for other totally unrelated projects.
More information about the Freeradius-Devel