I've been pinging "local-server" ever since I got Road Runner and Ping Plotter in the summer of 2001. Suddenly, during this past month most of time I cannot ping local-server. The final hop shows 100% packet loss. I asked tier 3 Oceanic Time Warner tech about it and he was unaware there was a problem and said he had just told another user to tracert to local server and they had no problems. However, when he tried he was surprised as he too could not ping "local-server" or typed as "hawaii.rr.com". He said Oceanic had not firewalled local-server so he had no idea what was the problem especially since the caller just before me was able to tracert to it just fine.

A few days later, I noticed that I could again ping local-server. But for the last several days, again I cannot ping it. What would be causing the problem if the ISP did not deliberately firewall it? Oceanic never replied to three emails I have sent this month regarding this issue.

Hi.

This is difficult to speculate on, since we've not heard of people having this problem and we've certainly not heard anyone have an answer.

One possible issue is if the IP Address of local-server has changed. To check this, start a new instance of PingPlotter and try tracing to local-server in that instance. Check and see if the results are different (and in particular, if the IP Address for local-server is any different than it is in your long-running instance of PingPlotter).

I *assume* that this server is responding to other kinds of requests (ie: if you try to access it via your web browser, that it responds that way). If this is the case, a possibly useful exercise would be to see if packets of a different type are getting through. Try switching to TCP or UDP packets and see if the results are different that way.

You'd think that a tier 3 tech would know what's happening with network configurations, but it may be that there was a software upgrade (or similar) done to some peice of hardware near / at local-server that started blocking ICMP echo requests or replies. It's good that the tech saw the same results you did - that way you know it's not a local-to-you problem.

If local-server is accessible via FTP or HTTP client, then you should be able to access the server with PingPlotter using the TCP packet type. That certainly doesn't answer the problem of "What's going on?", but it might work around the issue and still allow you to use PingPlotter to monitor your connection to that server.

- Pete

The IP address for "local-server" aka "hawaii.rr.com" hasn't changed in all the years I've had Road Runner. I have very old Ping Plotters so I can look back over the years and same IP always. I tried a new instance to both local server and hawaii.rr.com and same IP address still. I still get 100% packet loss on the final hop.

I switched to UDP packet type and got errors on all 5 targets. That has never worked for me but I have no idea why. I also tried ICMP raw sockets and that did not produce errors but didn't get through to local server. I suppose I should know this but how do I switch to tcp packets? I don't think it accessible via FTP but HTTP yes.

I can point my browser to 216.235.38.1 and get to hawaii.rr.com easily. As for the tier 3 tech being ignorant of this problem, he is one of Oceanic's best and has been there since before I got RR in June 2001. Sadly, it is not at all surprising that tier 3 might be in the dark about some configuration change that accidentally caused this. Oceanic is notorious for not communicating well with its employees. There is a user on Oahu (I'm on the Big Island) who gets 100% packet loss on the hop that is his UBR if he pings yahoo or some other site. Users at dslreports have told him that it is common for ISPs now to firewall routers. I don't believe for one minute that Oceanic has firewalled that particular UBR. I think there is some odd something going on much like whatever is causing me not to be able to ping local-server.

A few days later when I could ping local-server again, I happened to mention it to a former tier 3 tech who now is Oceanic management and he laughed about the tier 3 tech who had the same experience I did and then never actually told me what the problem was. We had a far ranging conversation about the network and I wasn't that concerned since it appeared fixed and I was more interested in getting some other questions answered. Then a couple of days later the problem began again and I wished I had gotten him to tell me exactly what caused it. He is not easy to contact but I will try as I really want to know what is going on! (Even if it starts working again suddenly).

I was hoping this was some common problem that you were familiar with. Leave it to me and Oceanic to come up with something weird. The tier 3 tech said to me (somewhat joking and somewhat serious) that Oceanic depends on me to find all the problems for them. I am well known to all tier 3 techs and they like that I run Ping Plotter because I sometimes see a problem before anyone else and I let them know and because I am online most of the day most days they have been able to fix a field problem that day before dark. I've been told that I alert them usually 3-6 hours before anyone else.

I am uploading an image of PP at the exact time on Feb 23 that local server again became unreachable. The graph shows 33% packet loss just before the 100% loss.

For TCP, you need 2.60 or higher. I sent you an email with some instructions on how to upgrade a week or so ago, and then another one yesterday. If you didn't get those, shoot an email to support@pingplotter.com and we'll make sure we get you going.

Just as an encouragement to use TCP, I just tried tracing to hawaii.rr.com from here - and with ICMP, it's not reachable (all hops up to it is, though!), but with TCP, it I get a response.

Hi Pete,

I just sent you an email. I did get the original email about the new version on Feb 22 and your latest email a few hours ago.

That is interesting that you also can't reach the final hop using ICMP. I'll have to install 2.60. I figure I will need to reboot after installing and it has been interesting to go for a couple of weeks (longest I ever have on XP Pro) without rebooting...so I have been reluctant to do anything that will mean a reboot.