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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
