On 12/12/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote: > Raimo Niskanen wrote: > > Interesting for me too, and most probably for others. It became an > > interesting discussion of my CLOSE_WAIT "problem" after all... > > > > To summarize (as I see it): > > > > * pf "synproxy state" does not affect these CLOSE_WAIT sockets since > > the SYN proxy is only active during connection establishement. > > But it is a good to use anyway since it prevents IP spoofing. > > Why not? Just test it out. What happen if you get a DDoS on your httpd > as an example, or try to connect to it. You send a packet to httpd, it > will create a socket to reply to your connection request and send the > source IP ACK and then wait for the reply ACK that will never come. So, > what does this do to your httpd then??? How many sockets will you have > pending responses here? You use one socket per user connection to your > httpd. You have 25 real users accessing your httpd and 1,000 fake users > without pf in the path. I will aksed you this simple question then.
don't confuse the CLOSE_WAIT with a SYN flood. if httpd doesn't close its socket, the proxy will neither. And even if it did, this doesn't close httpd's socket. I think I'm repeating myself, but the problem is *not* that httpd waits for any client data. I _has_ seen the clients FIN (or it wouldn't go into CLOSE_WAIT), but keeps its side open. > the close process have three stage as well. The client asked to close, > the server reply and the client confirmed. So, close, ACK and ACK. not exactly. the long version is: the side which wishes to close sends FIN, other side sends ACK (4-way-close: each side sends a FIN and an ACK). If the other side, which receives the first FIN decides to close also immediately, it can combine the FIN and the ACK (FIN - FIN/ACK - ACK). > > Did you verify that the client sent the last required ACK to the > original request of the server to close? If the server closes first and the client doesn't ACK, the socket should be in TIME_WAIT. After some time, I think, the server may send a RST if the client doesn't ACK its FIN. > There is also a keep alive in the tcp stack and if I remember well I > think it is set by default by the RFC is not a small amount of time. yes, TCP keep alives are empty ACK packets (or 1 octet payload). but while the TCP connection is open (while TCP keep alives might be sent), the socket doesn't go into CLOSE_WAIT. it does when the client FINs its connection, which should also end the sending of TCP keep alives > Again, are you sure all the RFC process was done? Who is waiting on who > here? Also, I think you may be confusing a few things here. httpd not > closing a socket and having "KeepAlive is in effect" are contradictory. in theory, they are simply not related, because on different protocol layers. Practically there seems to be a correlation by implementation. --knitti
