Internet troubles -- "Hackers" or Y2K?greenspun.com : LUSENET : Grassroots Information Coordination Center (GICC) : One Thread |
In a previous post (http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=002B3y) titled "Part of the Internet is down -- or is it just exodus.net?" I tried to call attention to my observation that websites I had been able to reach in 1999 were difficult to reach in 2000. Other people have noticed their internet connections are flakier than in 1999. In fact, the latest headlines announce the failures of several prominent Internet Web sites, blaming problems on "Hackers".I have noticed a LOT of problems reaching certain web sites from some ISPs and not from others. One ISP's Tech Support troubleshooters reluctantly admitted to me that they are having a lot of known routing problems they are trying to fix. Before that admission, they tried to drown me in doubletalk like "OK, we fixed the problem, we found you were plugged into the wrong port" and I surprised them by countering all of their "fixes" by saying things like, "That doesn't make sense to me, because I think if I were plugged into the wrong port, I wouldn't be able to reach ANYTHING, not just a few things." Their reply: "Oh, yea, that's right."
I just tried to surf to http://www.sprintpcs.com/ and got a default Microsoft IIS server screen -- the default that appears when the server is installed but before any web content is added.
I then surfed to http://visualroute.datametrics.com/ -- a site that tests a network connection.
It returned "The TCP/IP stack on 'www.sprintpcs.com' appears to have a bug. It uses the incoming TTL as the outgoing TTL of an ICMP packet, which is causing the false hops at hops 10-18. Connections to HTTP port 80 are being rejected."
Discussion: TTL stands for "Time-To-Live" -- a number of 255 or less. The purpose of this field is to keep packets from circulating around the Internet and occupying space that other packets might need. When I originate an IP packet, my computer chooses a somewhat arbitrary number -- like 64 -- for the TTL. That tells the Internet routers that this packet is to die after it has gone through either 64 routers or after 64 seconds. The timing of the 64 seconds is determined by the routers. If a packet can't deliver a packet because one of the outgoing network lines is busy, the router holds that packet until it can release it on a free (idle) line -- it also decrements the TTL of each packet it is holding in memory each second. So, If a router gets a packet with a TTL of 64 it will automatically set the TTL to 63 when it releases the packet. It will also reduce the TTL for every second the router held the packet while attempting to deliver it. For example, if the router held the packet for 5 seconds, the TTL would be reduced by 5. A packet is no longer stored or routed after the TTL reaches 0.
ICMP is the type of packet used by the PING program. The site http://visualroute.datametrics.com/ created an ICMP test packet to trace the path to http://www.sprintpcs.com and discovered the TTL's were not being decremented by a router or the www.sprintpcs.com server ("the incoming TTL as the outgoing TTL of an ICMP packet").
HTTP port 80 is the port your web browser (Internet Explorer or Netscape) connects to on the destination computer by default. "Connections to HTTP port 80 are being rejected" says that the server is not responding to browser requests to give the browser a web page.
I have no way of knowing whether this is a network, router, server, or hacker problem.
Here is the entire report: (will try to maintain the format of the report, but I see it wants to wrap long lines and that may make it unreadable)
============================================================ === VisualRoute (tm) 4.2a report on 10-Feb-00 3:40:48 PM === ============================================================
Real-time report for www.sprintpcs.com [32.97.3.230] (90% done)Analysis: Node 'www.sprintpcs.com' was found in 19 hops (TTL=1). The TCP/IP stack on 'www.sprintpcs.com' appears to have a bug. It uses the incoming TTL as the outgoing TTL of an ICMP packet, which is causing the false hops at hops 10-18. Connections to HTTP port 80 are being rejected.
----------------------------------------------------------------------------------------------------------------------------------------------------------------- | Hop | Err | IP Address | Node Name | Location | ms | Graph | Network | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | | 38.203.83.4 | VISUALROUTE | * | | | Performance Systems International | | 1 | | 38.203.83.1 | - | ?Herndon, VA 22070 | 0 | x | Performance Systems International | | 2 | | 38.2.104.1 | fr.herndon.va.psi.net | Herndon, VA, USA | 0 | x | Performance Systems International | | 3 | | 38.1.45.11 | rc11.se.us.psi.net | Herndon, VA, USA | 1 | x- | Performance Systems International | | 4 | | 38.1.25.193 | rc1.se.us.psi.net | Herndon, VA, USA | 1 | x- | Performance Systems International | | 5 | | 38.1.10.9 | - | ?Herndon, VA 22070 | 1 | x- | Performance Systems International | | 6 | | 204.6.117.86 | - | ?Herndon, Virginia 22070 | 17 | -x-------- | Performance Systems International, Inc. | | 7 | | 165.87.28.131 | nyor1ar1-4-0-0.ny.us.prserv.net | ?Bedford, NH 03110-6528 | 14 | x- | IBM High Performance Computing and Communications | | 8 | | 165.87.95.253 | - | ?Bedford, NH 03110-6528 | 10 | x- | IBM High Performance Computing and Communications | | 9 | | 32.97.0.157 | - | ?Bedford, NH 03110-6528 | 13 | x---- | IBM Global Services | | 10 | 10 | | | | | | | | 11 | 10 | | | | | | | | 12 | 10 | | | | | | | | 13 | 10 | | | | | | | | 14 | 10 | | | | | | | | 15 | 10 | | | | | | | | 16 | 10 | | | | | | | | 17 | 10 | | | | | | | | 18 | 10 | | | | | | | | 19 | | 32.97.3.230 | www.sprintpcs.com | ?Bedford, NH 03110-6528 | 10 | x- | IBM Global Services | -----------------------------------------------------------------------------------------------------------------------------------------------------------------
-- Ray Strackbein (Ray@Strackbein.com), February 10, 2000