| To: | Peter Jeremy <peterjeremy@optushome.com.au> |
|---|---|
| Subject: | Re: Keep state connections randomly dropped |
| From: | Darren Reed <darrenr@reed.wattle.id.au> |
| Date: | Sat, 03 Mar 2007 15:57:18 -0800 |
| Cc: | ipfilter@coombs.anu.edu.au |
| Delivered-to: | sp-com-lists@consult.net |
| Delivered-to: | ipfilter-list@securepoint.com |
| In-reply-to: | <20070303233236.GH9421@turion.vk2pj.dyndns.org> |
| References: | <20070217023906.GO859@turion.vk2pj.dyndns.org> <20070303003701.GA8298@turion.vk2pj.dyndns.org> <45E95405.2080303@reed.wattle.id.au> <20070303233236.GH9421@turion.vk2pj.dyndns.org> |
| Reply-to: | darrenr@reed.wattle.id.au |
| Sender: | owner-ipfilter@coombs.anu.edu.au |
| User-agent: | Thunderbird 1.5.0.5 (Windows/20060719) |
If you read RFC 793, the transition from "CLOSE WAIT" to "CLOSED" is 2 * MSL. MSL = 2 minutes. So the "4 minute" timeout you're seeing is correct... I will look into what should happen if a SYN packet for a new connection arrives within that 2*MSL...quite probably TCP will create a new connection, so IPFilter needs to do something intelligent here... Some things to toss up: - expunge the existing session when the new SYN packet is created and create a new session (this could be difficult) - use the first SYN packet to advance the state to closed, drop the packet and the state entry and wait for the next SYN packet to create a new connection Darren |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | FreeBSD6.2 ipfilter 4.1.13 OOW-patch?, Roger Olofsson |
|---|---|
| Next by Date: | Re: insight on S10 ipfilter patch 125014-02?, Darren Reed |
| Previous by Thread: | Re: Keep state connections randomly dropped, Peter Jeremy |
| Next by Thread: | Re: Keep state connections randomly dropped, Peter Jeremy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |