Handing out duplicate IP addresses

[tnt at kalik.net]

>> Can I ask what happens when the module fails ?
>
>  If the module is allocated two IP addresses to the same user, it is
>failing in a big way.
>

It's the other way around. Not two IPs to the same user but same IP to
multiple users. It's a threading issue.

When multiple threads ask for an IP at the same time it is possible for
same IP to be issued to different users. That's because allocate-find
works 10 or more times faster than allocate-update. There is a chance
that several allocate-finds will complete before first allocate-update
makes the IP unavailable.

That's not such a problem. The point of failure is then on the NAS. It
will make one connection with that IP and refuse the others.

The problem is that first allocate-update will allocate IP to userA.
Second one will change the allocation to userB. Third one to userC etc.
Now, chances are that NAS will create the connection for the one that
completed *first* (userA) an refuse the others. So NAS will have IP
allocated to userA, and radius database to userB (or C or whichever was
*last*).

When that last user tries to connect again radius will release the IP as
stale entry for that user. Now the NAS will have this IP allocated to
userA while radius database will show it as free.

I think that best thing to do is to prevent subsequent updates by
altering the allocate-update (adding "AND expiry_time IS NULL" at the
end should do it). That way only first one will update the row while
others will fail (update 0 rows). It should be possible for logic to
detect that no rows were updated and fail the module.

Dave would like a more drastic solution - to reject the user in this
case. I think that's a bit OTT. You can always reject users using
unlang if some module fails. And if it just fails you can do some
fail-over/redundant stuff.

Ivan Kalik
Kalik Informatika ISP