rlm_sqlippool allocating duplicate IPs

[Phil Mayers]

Alan DeKok wrote:
> Phil Mayers wrote:
>> Ugh. Even worse, it doesn't actually re-authenticate the user; it
>> actually just tears down the IPCP layer, and then brings it back up
>> again USING THE SAME IP. Of course, since the "stop-clear" query has run
>> at that point and re-set the pool_key column to "0", so the 2nd
>> accounting start doesn't re-allocate the IP.
> 
>   Is there a MAC in the Access-Request?  If so, the IPPool module

Sadly not. It's from pptp (pppd) radius.so plugin, so the requests 
basically only contain:

  User-Name
  NAS-IP-Address
  NAS-Port = pppd_pty#
  Calling-Station-Id = the.vpn.client.ip
  Framed-IP-Address

For the moment I've worked around it by changing the stop-clear query from:

UPDATE ${ippool_table} SET \
  nasipaddress = '', pool_key = 0, callingstationid = '' \
  expiry_time = 'now'::timestamp(0) - '1 second'::interval

...to:

UPDATE ${ippool_table} SET \
  expiry_time = 'now'::timestamp(0) - '1 second'::interval

This allows the start-update query to "re-claim" the IP allocation. It 
should also be safe, since in my case the pool-key option is "NAS-Port" 
and the allocate-clear query will zero out any spurious / dead sessions 
before the accounting gets a chance to "eat" them.

Still - I'll admit to finding it a bit worrying. There are clearly cases 
when IPs can get lost.

The other options are to base the "WHERE" clause on the framedipaddress, 
which in my case is always present in the accounting.