On Thu, Nov 17, 2005 at 12:34:53PM -0600, Kevin wrote: > I think this is a key point -- the client is removing the quad from > TIME-WAIT and sees it as eligible for reuse, meanwhile the firewall > and/or the server still has this closed session state table entry in a > *WAIT state.
Yes. The client's table is relatively clean -- usually there is nothing except the blocking SYN_SENT. Both the fw and server have hundreds of connections in TIME_WAIT. > > the client sends 3 syns in rapid succession from this source port > > and the firewall doesn't allow them through. > . . . > > Now my problem is figuring out how to deal with this situation. > > I believe the firewall is doing what it should but others may argue it > > is being too strict. I could also just widen the defaut port range on > > the clients, but that doesn't strike me as the best solution. > > If 'pf' is blocking new SYN packets because of an existing FIN-WAIT > table entry for the same quad, that may be proper behavior, yet "too > strict". I don't believe pf is doing the blocking here, and if it is it sure isn't logging them as such. Based on what others have said and what I've read, this is the kernel at work. > My TCP is a little rusty, but would it be reasonable for the > "aggressive" optimization to not only adjust timeouts, but also change > engine behavior so a newly received SYN, if it matches a state entry > which is in FIN-WAIT or CLOSED state, to reset that state entry back > into "first"? I'm not too sure. I'm a bit hesistant about driving down tcp.finwait, tcp.closed and tcp.closing. Sure, maybe it will make these timeouts go away or simply occur less frequently, but not without introducing more issues. If I find out more, I'll be sure to let the list know. -jon
