Alan DeKok <aland@deployingradius.com>
Dave wrote:
Im still having trouble with this problem, I switched the pool key to NAS port, the expiry time is 24 hours, and it seems after 24 hours, it wipes all the existing entries from the database,
That would seem to fit the 24-hour expiry time you set.
again re-assigning IP's that are already in use, these IPs could be used indefinitely by some customers assuming they don't disconnect, I guess the sqlippool.conf seems to think that the stop packets are lost..?
No. The leases are set to expire after 24 hours, as you said.
If you don't want the leases to expire, edit the SQL queries so that they don't set or look for an expiry field.
I should probably leave this one to Peter to answer, but ... that wasn't my understanding of how the expiration works in sqlippool. The 'allocate-clear' query looks like this: allocate-clear = "UPDATE radippool \ SET NASIPAddress = '', pool_key = 0, CallingStationId = '', \ expiry_time = NOW() - INTERVAL 1 SECOND \ WHERE pool_key = '${pool-key}'" Which, by my understanding, should only clear IP's for which we are seeing a REPEAT login on the same 'pool-key' (although I think it should probably add a test for the same NASIPAddress in the WHERE clause, I keep meaning to ask Peter about that). In other words, it should only be clearing IP's for which a 'stop' query has gone astray, on the basis that you can't have more than one connection to an individual NAS port. It certainly shouldn't just free up all IP's based on expiry_time. I did see one 'rogue' SQL file out there from a very early version of sqlippool which does seem to use expiry_time - not sure if it was an original, or a contributed version, but it was definitely broken. Dave - can you copy and paste your sqlippool.conf, so we can see what your actual queries look like? -- hugh