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.