Joe_Cool, it very well might help to see a pattern to the IP addresses.
Here’s what I’ve found out. I’m in the Dallas area on a DSL line. The final router before the Chicago Reader itself is the same one the Joe_Cool fails on (146.188.208.77), yet mind works fine, so I doubt it’s a router problem.
ISP’s have no control of the packets once they are passed to a backbone except that they may have some ability to help figure out what is wrong. These traces are dying at the very end of UUNET’s backbone. (router names that end in ALTER.NET are part of UUNET’s network. The part just before that tells the city or location, (CHI6=Chicago, NYC9=NY City, etc.) So, I doubt it’s an ISP problem directly.
I’ve gone to a site that allows you to run traceroutes from their servers and ran several traceroutes from various places. They all worked fine.
I ran traces from the areas that people have reported problems, Joe_Cool connects to UUNET at NYC, tevya connects at Washington DC, Bosda is in Tennesee, DDG is in Indiana, there is someone here in the DFW area that can’t get through. By using these other servers, all the routes seem to work from all over. There seems to be a few routers on the last hop before connecting to the Chicago Reader (146.188.208.77, 146.188.208.73, 146.188.208.69, and 146.188.208.65.) I’ve seen all these show up on good traces.
So, what have I figured out? Very little. One thing is the the return path isn’t necessarily the same as the forward path, which is what you see on the traceroute. That means there could be a bad routing table that is sending the acknowledgements off in the dust instead of the request. That’s not very likely though.
The real curious thing I did notice, (you just knew I was getting around to something, didn’t you?) is that some of the traceroute sites gave a TTL value along with other info about the trace. TTL means Time To Live. It is suppose to be decremented by one for each router that the packet passes throught. When the TTL value gets to zero the packet is discarded. The traceroute sites start with a TTL of 255, but the curious thing is that although TTL might be 248 right before the Straight Dope’s router (65.201.198.1), but it returns a TTL=55. The Straight Dope server (65.201.198.9) returns TTL=246. That would mean that the 65.201.198.1 router decremented the TTL count by 193 instead of 1. That just doesn’t seem right.
I don’t know the significance of that and whether it would effect some services and not others, but it may be something for the techs to look into.
Jim