Hello Everyone I am hoping to use rlm_ippool and I would like to understand a bit about how it works. Firstly I want to understand the format of the database. I can see from the output of rlm_ippool_tool that there are five columns :- Key | IP Address | Active | CLI | Num It is obvious what the first two are, and I am not sure about the last three, but I guess that "active" means that this address is in use. Could anyone explain to me what the columns "cli" and "num" are used for? I noticed that this module is called from the post-auth and accounting sections, and in the accounting section of sites-available/default there is the following comment :- # Return an address to the IP Pool when we see a stop record. Does this mean that the ippool module sets "active" to 0 when it sees an accounting Stop from the same "Key"? Also, I noticed that this module can be used for DHCP which obviously does not have an accounting section. Does this mean that IP addresses can never be deallocated from the pool? Thanks in advance for any help. Ben
Бен Томпсон wrote:
I am hoping to use rlm_ippool and I would like to understand a bit about how it works. Firstly I want to understand the format of the database.
The best approach is to look at the documentation, followed by the code.
Could anyone explain to me what the columns "cli" and "num" are used for?
I haven't looked at it myself. All I know is that it works.
Does this mean that the ippool module sets "active" to 0 when it sees an accounting Stop from the same "Key"?
No idea. Look at the code.
Also, I noticed that this module can be used for DHCP which obviously does not have an accounting section. Does this mean that IP addresses can never be deallocated from the pool?
No. The addresses should have a lifetime. Alan DeKok.
Thanks Alan 2013/2/12 Alan DeKok <aland@deployingradius.com>:
Бен Томпсон wrote:
I am hoping to use rlm_ippool and I would like to understand a bit about how it works. Firstly I want to understand the format of the database.
The best approach is to look at the documentation, followed by the code.
I have had a look at the code and have been able to work out a few things. I will write my findings here, both for my own reference and for others who might ask the same questions in the future. Regarding the "active" flag: as I understand it so far, this is basically supposed to indicate whether a session (e.g. PPP,) is currently up and using this address. The theory being that the flag is set to 1 when the IP is dished out during RADIUS post-auth, and it is set to 0 when the accounting stop is recieved. I also figured out that "cli" flag is the Calling-Station-Id and this is used as an identifier in Multilink PPP sessions. It would appear that in the old days of bundling together conections with dial up modems (to get more bandwidth) it was necessary to issue the same address in mutliple authentication requests. One thing I still don't understand though is how best to use ippool for DHCP. I don't understand where and how I should call the module during a DHCP transaction. For example I can call it during DHCP-Discover, but it seems that if I call it again during DHCP-Request I might get different address even when the key is the same. I will continue to to study the code to see why this happens and if I figure it out I will report back with my findings. If anyone else knows the answers, I would be grateful hear from them.
On 02/13/2013 07:23 AM, Бен Томпсон wrote:
One thing I still don't understand though is how best to use ippool for DHCP. I don't understand where and how I should call the module during a DHCP transaction. For example I can call it during DHCP-Discover, but it seems that if I call it again during DHCP-Request I might get different address even when the key is the same. I will continue to to study the code to see why this happens and if I figure it out I will report back with my findings.
With difficulty, in short. The ippool module is old, and predates the DHCP functionality. You would need to "fake up" some RADIUS attributes in the DHCP packet, then ensure that ippool is called in a manner that hands out IPs correctly. This may prove to be impossible. There is an example of doing this with the sqlippool module, which is rather better suited to this; by customising the queries you can ensure that different IPs in DISCOVER/REQUEST are not a problem. See the GIT repo for details: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/policy.d/d... https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/mods-avail...
participants (3)
-
Alan DeKok -
Phil Mayers -
Бен Томпсон