Hi, Ive noticed that rlm_ippool is nearly always reassigning an IP address that has just been releasing for a new connexion. This cause 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 ? Regards, Neopost Diva 127 avenue Joseph Pierre Boitelet BP50 84302 CAVAILLON Cedex FRANCE Sébastien, Cantos IT Manager <mailto:s.cantos@neopost.com%3c!--123mms_/email--%3e> s.cantos@neopost.com Phone: + 33 4 90 76 08 08 Fax: + 33 1 40 39 23 23 <http://www.neopost.com> http://www.neopost.com The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The Internet cannot guarantee the integrity of this message. Neopost shall not therefore be liable for the message if modified. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact <mailto:postmaster.diva@neopost.com> postmaster.diva@neopost.com and then delete this message.
Sebastien Cantos wrote:
I’ve noticed that rlm_ippool is nearly always reassigning an IP address that has just been releasing for a new connexion. This cause some TCP connexion problems because of the TIME_WAIT state.
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.
Phil Mayers wrote:
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.
Yes, that should be a solution. I was more thinking of adding a parameter to make sure an IP is kept used in the pool for a certain amount of time after a disconnection and before being available for allocation. I don't know what is more easy to hack. I'm going to try using my some little developer skills to look at rlm_ippool.c and see what I can do. If there are some freeradius developers around that could help I'll really appreciate. Regards, Sebastien.
Sebastien Cantos wrote:
Phil Mayers wrote:
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.
Yes, that should be a solution. I was more thinking of adding a parameter to make sure an IP is kept used in the pool for a certain amount of time after a disconnection and before being available for allocation.
Good idea.
I don't know what is more easy to hack. I'm going to try using my some little developer skills to look at rlm_ippool.c and see what I can do.
Your idea would be much easier, since there's code in the module to deal with expiry already. You'd need to change the code in rlm_ippool.c:ippool_accounting around line 392 (in the CVS) to be: entry.active = 1; entry.timestamp = request->timestamp; entry.timeout = 240; /* or whatever TIME_WAIT time */ ...and then remove the bit further below completely: /* Decrease allocated count from the ip index */ Be aware that, rather obviously, this will greatly increase the contention for IPs from the pool. If you find that a problem, you might need to increase the pool size or change the code in postauth (around line 645) to either aggressively age inactive entries, or to pass through again if no entries are free and force inactive the oldest one. Good luck!
participants (2)
-
Phil Mayers -
Sebastien Cantos