Re: rlm_ippool - not releasing ip addresses
Kostas Kalevras a écrit : I have some scripts here which will process a ip pool file (using rlm_ippool_tool) against radwho or a radacct table, which I used to clean out rm_ippool's data every so often. The problem is that any non-FreeRADIUS modification of the database needs to be done while FreeRADIUS is stopped. I'd love to improve rlm_ippool_tool, but if I ever work on it again, it'll be to SQLise rlm_ippool instead, (as I believe someone has done and posted a patch to the list), as part of my heartfelt desire to turn FreeRADIUS into some kind of unusual SQL database frontend. ^_^ Hmm, rlm_ippool can be a good candidate for sqlizing. Though it will need to use the rlm_sql functions (like radsqlrelay does). sql xlat is good for queries but in the case of rlm_ippool inserts/updates are also required which are difficult to implement through xlat. db is efficient, just need some perl around it. Personnaly, I don't want to install an sql server just in order to play with ippool. Keep it simple and easy. -- Dominique LALOT Ingénieur Système Réseau CISCAM Pole Réseau Université de la Méditerranée http://annuaire.univ-mrs.fr/showuser.php?uid=lalot - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ippool - not releasing ip addresses
On Sun, 21 Nov 2004, Paul Hampson wrote: On Sat, Nov 20, 2004 at 10:51:32AM +1030, Mike O'Connor wrote: Thanks for you comments, I used you suggestion as a biases and have found that the accounting stop records do not always have the same port id. This means it does not match correctly and does not release the port. I do not see any way of fixing this from the nas end, so I plan to write some software which checks if a port has been release (using the Alive and Stop records) and then sends a Acct Stop record with the correct port details. In most cases this won't be a problem, as a new ippool call with a port number rlm_ipaddr thinks is still in use should free the IP address up, so it can later be reallocated. Yap It's a problem if you have more ports than IP addresses. ^_^ (As I do here. _) I tried using radkill, but that was more trouble than worth, as the radutmp file was getting boned for entirely different reasons. If you have more ports than IPs and your accounting does not work right then there's not really anything you can do to make things work. I have some scripts here which will process a ip pool file (using rlm_ippool_tool) against radwho or a radacct table, which I used to clean out rm_ippool's data every so often. The problem is that any non-FreeRADIUS modification of the database needs to be done while FreeRADIUS is stopped. I'd love to improve rlm_ippool_tool, but if I ever work on it again, it'll be to SQLise rlm_ippool instead, (as I believe someone has done and posted a patch to the list), as part of my heartfelt desire to turn FreeRADIUS into some kind of unusual SQL database frontend. ^_^ Hmm, rlm_ippool can be a good candidate for sqlizing. Though it will need to use the rlm_sql functions (like radsqlrelay does). sql xlat is good for queries but in the case of rlm_ippool inserts/updates are also required which are difficult to implement through xlat. -- Paul TBBle Hampson, on an alternate email client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ippool - not releasing ip addresses
Hi Paul Thanks for you email. I sat down this weekend and wrote the same type of tool. I find all the ip address which have been left active, read out of the radacct database a closed record for each ip address. Then use radclient to send a radacct stop record for each ip address but change the nas port the one reported by rlm_ippool_tool. You mention that the problem only happend if there is not enought ip for the total ports. If I have understood you correctly, I have to disargree. For this site we have 25 port and 30 ip's. Thanks Mike Paul Hampson wrote: On Sat, Nov 20, 2004 at 10:51:32AM +1030, Mike O'Connor wrote: Thanks for you comments, I used you suggestion as a biases and have found that the accounting stop records do not always have the same port id. This means it does not match correctly and does not release the port. I do not see any way of fixing this from the nas end, so I plan to write some software which checks if a port has been release (using the Alive and Stop records) and then sends a Acct Stop record with the correct port details. In most cases this won't be a problem, as a new ippool call with a port number rlm_ipaddr thinks is still in use should free the IP address up, so it can later be reallocated. It's a problem if you have more ports than IP addresses. ^_^ (As I do here. _) I tried using radkill, but that was more trouble than worth, as the radutmp file was getting boned for entirely different reasons. I have some scripts here which will process a ip pool file (using rlm_ippool_tool) against radwho or a radacct table, which I used to clean out rm_ippool's data every so often. The problem is that any non-FreeRADIUS modification of the database needs to be done while FreeRADIUS is stopped. I'd love to improve rlm_ippool_tool, but if I ever work on it again, it'll be to SQLise rlm_ippool instead, (as I believe someone has done and posted a patch to the list), as part of my heartfelt desire to turn FreeRADIUS into some kind of unusual SQL database frontend. ^_^ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ippool - not releasing ip addresses
On Sat, Nov 20, 2004 at 10:51:32AM +1030, Mike O'Connor wrote: Thanks for you comments, I used you suggestion as a biases and have found that the accounting stop records do not always have the same port id. This means it does not match correctly and does not release the port. I do not see any way of fixing this from the nas end, so I plan to write some software which checks if a port has been release (using the Alive and Stop records) and then sends a Acct Stop record with the correct port details. In most cases this won't be a problem, as a new ippool call with a port number rlm_ipaddr thinks is still in use should free the IP address up, so it can later be reallocated. It's a problem if you have more ports than IP addresses. ^_^ (As I do here. _) I tried using radkill, but that was more trouble than worth, as the radutmp file was getting boned for entirely different reasons. I have some scripts here which will process a ip pool file (using rlm_ippool_tool) against radwho or a radacct table, which I used to clean out rm_ippool's data every so often. The problem is that any non-FreeRADIUS modification of the database needs to be done while FreeRADIUS is stopped. I'd love to improve rlm_ippool_tool, but if I ever work on it again, it'll be to SQLise rlm_ippool instead, (as I believe someone has done and posted a patch to the list), as part of my heartfelt desire to turn FreeRADIUS into some kind of unusual SQL database frontend. ^_^ -- Paul TBBle Hampson, on an alternate email client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ippool - not releasing ip addresses
Mike O'Connor [EMAIL PROTECTED] wrote: There are 30 address in the pool and at this time 13 of these are listed as active but the radacct record show that the users using these address's have logged off. Maybe the ippool module isn't getting the information it needs to release the address. Run the server in debugging mode ot see. Or, look at the detail file for sessions where the address isn't released. Run a test server in debugging mode, and send copies of those packets to the server, and see what the ippool module does. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_ippool - not releasing ip addresses
Hi Alan Thanks for you comments, I used you suggestion as a biases and have found that the accounting stop records do not always have the same port id. This means it does not match correctly and does not release the port. I do not see any way of fixing this from the nas end, so I plan to write some software which checks if a port has been release (using the Alive and Stop records) and then sends a Acct Stop record with the correct port details. If any one has a better idea please email the list. Thanks Mike Alan DeKok wrote: Mike O'Connor [EMAIL PROTECTED] wrote: There are 30 address in the pool and at this time 13 of these are listed as active but the radacct record show that the users using these address's have logged off. Maybe the ippool module isn't getting the information it needs to release the address. Run the server in debugging mode ot see. Or, look at the detail file for sessions where the address isn't released. Run a test server in debugging mode, and send copies of those packets to the server, and see what the ippool module does. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_ippool - not releasing ip addresses
Hi All I have an issue with freeradius 1.0.1 not releasing some ip address back to the non active pool. There are 30 address in the pool and at this time 13 of these are listed as active but the radacct record show that the users using these address's have logged off. The rlm_ippool_tool has an option '-r' which I thought would fix this but it removed the ip address from the database instead. Any help with this would be greatly appreciated Thanks Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
