If you were blocked, you would get a message saying that your IP was blocked and explaining why. More information about that message is available here: Why you shouldn't rip this site.

Here are some questions to help figure out what is going on:

Can you reach:

http://66.13.172.18/techref/index.htm ? If so, the problem is DNS. Verify that you can get to other sites (e.g. Google ) and if so, contact me.

Can you reach:

http://www.quickstepper.com ? If so, the problem is with the headers sent back by the PICList site. Quickstepper is on the same server but is a very simple, "out of the box" configuration of IIS. PICList has a batch of stuff installed. Why some people can deal with it and other can't is an ongoing mystery. It may be caused by a problem with some node in the route between your ISP and mine, or by your browser, or god knows what.

If you can't reach any of them, your ISP or something between your ISP and mine is messed up. They will never believe this, but you can prove it to them by using a proxy server on another network.

For example:

<http://www.the-cloak.com/Cloaked/+cfg=32/http://www.piclist.com/techref/piclist/index.htm> After you click on this link, it will ask you for some configuration info and you should check the URL in the lower left corner to ensure it is still http://www.piclist.com/techref/piclist/index.htm (sometimes the "http:" turns into "http%3A" or the "//" becomes a "/") then press the "Start Surfing" button.

If you see the web site, search the page for the text "local time: " and make a note of the servers clock setting. It should show PDT (Pacific Daylight Time) or PST after daylight savings ends.

Hit refresh and verify that it is changing. If it is changing, then the server IS up and you are NOT viewing a cached copy.

If you see the web site, and the time is updating, the web server is UP. If you cant see the site directly, then your ISP, or their upstream and nothing else, is the problem. Do a tracert 66.13.172.18 from the command prompt and email the result to your ISP's tech support along with your findings to the questions above and this email.

Black Hole Routers

http://support.microsoft.com/kb/159211/EN-US/  Diagnoses and Treatment of Black Hole Routers

Ping 66.13.172.18 -f -l 1472

That is "minus lower case F space minus lower case L" and then a number. If 1472 doesn't work, try half that, then half that, and so on, until you get a response.

ping 66.13.172.18 -f -l

Hector Martin says:

My bets are on my initial guess: your MTU is too high and your server is sending DF. Headers are sent separately. Clients behind a node with a stricter MTU limit will drop all packets, but HTTP headers get through.

OTOH, I've tested some other sites and they use DF and high MTUs too, but when I lower the MTU at my DSL router, they respond by (correctly) using lower packet sizes, i.e. Path MTU discovery is working fine. piclist.com keeps sending me 1506 byte packets.

In the end, it turned out that a bug in the firewall firmware was causing the problem. Eventually, new firmware was released and corrected the problem for us.