Read up on syn floods here: www.cctec.com/maillists/nanog/historical/9609/msg00397.html



The question is, what is causing this?

To pinpoint it, stop apache completely on your box. Then proceed to see if you can trigger the error condition. If you can, it's not apache.

It's too hard to figure out the rest, there are too many variables. Since this only happens when trying to access your sites on the remote server, it should not be related, but may be.

You may also have spyware of some type, or your system may be hacked and might be trying to gain access to your remote site only, which is odd, but possible. So your router shuts down the attack. Or something like that.

To localize this, I would strongly suggest trying kanotix, a fine german linux, run it off the live cd, see if you can trigger the error condition. If you can't, my guess is you may have spyware on your box of some type or other.

If children or non tech savy users use this computer then it has spyware, almost 100% guaranteed.
Back to top

My second guess, more likely, is that your web server just sucks. It's got some bug, some apache misconfiguration, and is simply not handling requests correctly. A glitch possibly triggered by repeat visits to the site. Possibly this glitch triggers a firefox glitch in return.

If you read the above, you'll notice that it's possible that your remote server is simply not sending back the stuff to your machine, so your machine starts sending out more requests, in a loop, until your router shuts it down. Something like that.

I can safely say I've never had this issue, or seen anything like it.

Every time I use a hoster that is not Pair Networks, I find new and fascinating ways for a server to be misconfigured, improperly setup, act inconsistently, etc. My favorite is when they change the security policy of the server without telling the clients, thus crashing the site programming. Yes MediaTemple and Segment, I'm talking about you.

With a few notable, and very expensive, exceptions, like rackspace for example.

To properly diagnose this issue, you'd probably have to run ethereal network packet analyzer and study the actual requests and responses, but it's too hard to explain how to do that to someone without the necessary background, though it's not technically hard to run the gui version. Ethereal just got renamed to wireshark due to some unfortunate circumstances, wireshark is the real product, another company owns the ethereal name but not the code or the developer.

I would download wireshark, start it up, start collecting network information, create a request on the browser that succeeds, save the packet session, then browse until the lockup condition occurs again, then start a new wireshark packet sniffing session, create a request that fails, save that session as well, then start looking at the physical packets of the session that failed to see if you can see any patterns. Very complicated to do, headache.

But it's almost, but not quite, certain, that this is a remote apache server misconfiguration, that's what I lean towards. My guess is it's not returning 304s like it's supposed to do for already cached files, but is sending out some garbled signals instead. Which might be why other visitors don't see it, only you. Any brand new browsing session might solve the issue, or might not, depends on how you have your browser set.

The last time I saw this issue was with one of the worst webhosters in the world, ci host, they had misconfigured the mimetypes for css, it took me ages to figure it out, the bug would trigger in one and only one circumstance: the end user was using aol as an ISP. The aol caching system failed to store the incorrectly typed css, or served it up incorrectly, or the aol browser handled it incorrectly, and that resulted in my client, an aol user, seeing a plain html page, not very impressive.

Once the css mimetype was corrected, the issue went away. But it only happened on one isp, aol.

Running wireshark will show you this as well by the way, it will show the mimetype for each and every packet required to build your web page.

If you don't want to use that, you can simply use the great extension Live HTTP Headers, which will show you the mimetypes of each packet. I would not be surprised if some of them are wrong.
Back to top

by the way, the site itself looks nice

The Firefox.css has errors in it.

Validate it here: w3.org css validation
Back to top

Hi jeffd,

Thanks so much for all your latest suggestions on this. I haven't had to do any of it, because since I moved the directories for the two sites in question to another partition on my drive, then moved them back,

I can't duplicate the problem.

It's totally strange. I've got this thread bookmarked, and if the trouble starts torturing me again, I'll come back and try some of the things you suggested. For now, it's fixed, though I don't understand why.

Thanks again for all the thought you put into this for me. I appreciate you spending your time on it!
Back to top