Guy Fraser <guy@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.
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. 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. Damn... Alan DeKok.