I'm re-mailing this post from comp.security.firewalls, because the
Frontier person I've been dealing with has come up with confirmation that
their stack is responsible for bringing down one of my web servers.
I'd like to thank the Frontier folks for responding in a decent and timely
manner to me, especially since I'm not a direct customer of theirs.
If you've got users running the SuperTCP stack, *please* have them
upgrade, some of us can't take the downtime on our servers :)
Symptons are lots of sockets on the server side in a SYN_RCVD
status from the same IP address, until your Listen Queues fill up, and the
httpd stops responding until (and if) it times out the sockets, or you
Fix is unfortunately to screen out the offending client, and try to
contact them. Alternate fix is to run something that will clear out the
sockets in SYN_RCVD state if you get nnn of them from one host (be
careful, some hosts *could* have a few hundred users hitting your site
through a proxy). This will depend on your listen queues. We had our
listen queues set at 224 when our server went down, the Netscape client
just loves to loop through that connect(). We're now at 1024, with the
ability to go up to a _REALLY_ big number (~2 billion assuming enough
storage on the box) (AIX 4.1.4 with kernel patches).
John McPhail (jmcphail @
com) Stood upon their soapbox and shouted:
: Hi -
: I had a flood attack a while back that jammed open way too many
: sockets on port 80. It was beginning to be effective by the time we
: blocked it at the router.
: It is now being blamed (in some quarters) on a mis-configured or buggy
: tcp/ip stack for windows called SuperTCP, by Frontier Technologies.
: Can anyone else verify this? I haven't recieved any response from
: Frontier, and I really don't want to swallow this story without
: something to back it up.
I've gotten mail from Frontier confirming the problem, and a client-side
fix for the problem. This is the result of a follow-up after a flood of
one of my web servers.
"What is the version of the SuperTCP stack. If it is pre WinsockB, then it
has the Netscape BUG. Were Netscape would not recognize an invalid socket
as -1 only. After that release, we will not use negative socket numbers
unless we already have 128 sockets open. If the user has a version of our
product with a kernel version prior to 4.32 (check the kernel window Help
| About), they should download
Please note that this is directly from the reply from Frontier, who were
very helpful once they had the client info.
: I really appreciate any responses. If you wish to e-mail me, please
: do so at:
: jmcphail @
Mail directly hasn't gotten a response.
: Thanks again -
: -John McPhail
Paul D. Robertson "My statements in this message are personal opinions
net which may have no basis whatsoever in fact."