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@neopost.com] Envoyé : mercredi 19 juillet 2006 14:17 À : 'freeradius-devel@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.