Re: ipfw drop syn+fin
On Fri, Feb 23, 2001 at 10:34:57AM +, Alex Hayward wrote: > On Thu, 22 Feb 2001, Tom wrote: > > > On Thu, 22 Feb 2001, Alexandr Kovalenko wrote: > > > > > # TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This > > > # prevents nmap et al. from identifying the TCP/IP stack, but breaks support > > > # for RFC1644 extensions and is not recommended for web servers. > > > > > > I'm wondering _why_ it is not recommended for web servers? > > > > Because RFC1644 extensions are valuable for web servers, and client > > clients use them when making web requests. So guess what happens when > > your server drops requests using RFC1644 extensions? > > Since what it does is cut the connection open/close time (well, it > shortens the TIME_WAIT time, too, but I doubt that's so important...) from > 7 packets to 3 it's not quite so important in these days of persistent > HTTP connections. Oh, and it can't be used for the first connection a > client makes since the server needs to cache a connection count from each > client which is passed in a TCP option. Both server and client need to be > written in a particular way to take advantage of it, too. > > Oh, and nothing that I've found supports it apart from FreeBSD; which has > it turned off by default. I'd be interested to know if anyone knows any > different... I know this isn't really a major platform, but the Miami TCP stack on the Amiga supports it, along with at least one of the browsers which runs on the Amiga :) -- Simon Dick [EMAIL PROTECTED] "Why do I get this urge to go bowling everytime I see Tux?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ipfw drop syn+fin
On Thu, 22 Feb 2001, Tom wrote: > On Thu, 22 Feb 2001, Alexandr Kovalenko wrote: > > > # TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This > > # prevents nmap et al. from identifying the TCP/IP stack, but breaks support > > # for RFC1644 extensions and is not recommended for web servers. > > > > I'm wondering _why_ it is not recommended for web servers? > > Because RFC1644 extensions are valuable for web servers, and client > clients use them when making web requests. So guess what happens when > your server drops requests using RFC1644 extensions? Since what it does is cut the connection open/close time (well, it shortens the TIME_WAIT time, too, but I doubt that's so important...) from 7 packets to 3 it's not quite so important in these days of persistent HTTP connections. Oh, and it can't be used for the first connection a client makes since the server needs to cache a connection count from each client which is passed in a TCP option. Both server and client need to be written in a particular way to take advantage of it, too. Oh, and nothing that I've found supports it apart from FreeBSD; which has it turned off by default. I'd be interested to know if anyone knows any different... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ipfw drop syn+fin
> > Say a web client has a few connections to a web server. One of those > > connections is retriving an image (for example). When it's finished, it > > will send a FIN to the server to close that connection. However, at the > > same time, the web client wants to open a new connection to the same > > machine, which requires a SYN to be sent. The smart TCP/IP stack on the web > > client will set both the SYN and FIN bits in one packet, which means "close > > this connection, and open a new one." > > No, it means open this connection with this data then start to > close it as this is the only data I am going to send you. It > saves a few round trip times. I stand corrected. (Now that I've had a chance to think about it, what I explained is impossible!) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
