rlm_ippool and tcp TIME_WAIT state

[Sebastien Cantos]

Hi,

 

I’ve coded a little patch for 1.1.2. If someone is interested in this and
has some time to test (I’ve done lots of tests using radclient) it may be
interesting to include the patch in the CVS.

 

Regards,

 

Sebastien. 

 

  _____  

De : Sebastien Cantos [mailto:s.cantos at neopost.com] 
Envoyé : mercredi 19 juillet 2006 14:17
À : 'freeradius-devel at lists.freeradius.org.'
Objet : rlm_ippool and tcp TIME_WAIT state

 

Hi,

 

I’ve already posted this to the user’s mailing list, but I think that here
is a best place for this. 

 

I’ve noticed that rlm_ippool is nearly always reassigning an IP address that
has just been releasing for a new connexion. This causes some TCP connexion
problems because of the TIME_WAIT state. 

 

Scenario:

1/ one device connects using source port 1024 (ppp) and gets an IP address
from freeradius

2/ this device disconnects, the ip is freed from the pool

3/ another devices connects using source port 1024 and gets the same ip
address as before

4/ the connexion is impossible to the server because the connexion of last
device is still in TIME_WAIT state

 

How can I make sure an IP address is not assigned before some time period
(240 seconds, time period of the TIME_WAIT state) after being released? 

 

I got one answer :

 

>Interesting.

>The IPs are allocated by a GDBM walk of the database, and use of the first
free or expired IP. This will always tend to be the same one hence the
repeat >allocations.

>It would in theory be possible to save the key from the last walk, and next
time we allocate an IP start from that key and wrap back around, which would
>allocate IPs in a more round-robin fashion.

 

I would appreciate if someone can help doing the hack or give me some hints
to modify rlm_ippool.c to add some retention time parameter to make sure an
ip is not reassigned instantly after being freed or to make things work more
in a random or round robin way. 

 

Thanks in advance. 

 

 

Regards,

 

Sebastien. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20060725/786caece/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: retention-time.patch
Type: application/octet-stream
Size: 17122 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20060725/786caece/attachment.obj>