PP works fine with my RoadRunnerconnection, which assigns a dynamic IP address. However, on Verizon FIOS (fibre optic) I get a zero round trip time connected directly to their Router, which has a static address. No Hops are shown.

The display shows the IP address of the pinged site, but 0,0 for round trip.

I have no problem accessing the internet, just cannot get valid traceroutes with PingPlotter.

Suggestions?

This definitely sounds like a problem with the router. Where (which hop) does the final destination show up with 0ms latency?

A 0 round trip time to the first hop isn't abnormal, but not showing any intermediate hops and showing 0 ms to the final destination sounds like a TTL Expired bug in the router. I would check for a bios update for the router. I'd also try the command-line TRACERT command to see if it behaves any different. There might be a problem with multiple outstanding requests in the router.

If you post a screenshot of what you're seeing (you can attach a .png image to a post), then we may be able to offer additional suggestions (based on the hop the final destination is responding).

- Pete

Here is pingplotter and tracert Note the subtle difference...

OK, so "Edit" is turned off and so is "Attach." Hmmm..

I disremember the 'net site that lets you post images on the web. Let's see if "Attach" comes up when my registration goes thru (:

I was unaware of this, but it looks like you do have to be logged in to add an attachment. For editing, you definitely need to be logged in. Just create an account (which is pretty much instant), and that should get things working for you.

Done.

See message 3 re: tracert and pingploter graph.

And..

Yup - that's a bug in your router bios (whatever is at hop 1).

It looks like it's changing the source IP address for all of the returning ICMP TTL expired packets to be the target's IP address. That's one I've not seen before.

I would get ahold of Verizon and see what they have to say about this. You *may* have better luck reporting the problem with TRACERT instead of PingPlotter, since TRACERT is more pervasive (since it's installed on all machines).

Actually, the *first* thing I'd do is look to see if there's a bios update for the router (the one physically at your location), since that's probably the culprit.

Based on this behavior, I don't think there's any setting you can change in PingPlotter to change this behavior. You might try TCP or UDP packet types, just to verify, but since it looks like it's a problem with the NAT handling on the returning ICMP TTL Expired packets (and that is the same packet types UDP and TCP use), you'll probably see the same results with those types as well.

Please post back here if you make any progress or breakthroughs on this problem (or if there's anything else we can do to help).

- Pete

Progress.

For your reference, Verizon 888-553-1555 is supposedly Tier III suport for the Actiontec M1424WR router on my FIOS system.

Their first response to why PP and Tracert work on RoadRunner and not FIOS is "Its a firewall issue." After a little pushing they decided it was THEIR firewall, the one built into the Actiontec M1424WR router.

They suggested I contact you and find out if your program uses PCP or UDP and get back with them to have them help me setup the router to use Port 40.

This is a little over my head, but i'm hoping the Verizon FIOS market for Pingplotter is big enough you can afford to help me <img src="/forums/images/graemlins/smile.gif" alt="" />

PingPlotter Standard does both UDP and TCP. It doesn't do "PCP", although I'm really not sure what PCP is in relationship to tracing. Since this was a phone call, maybe they said "TCP"?

Both UDP and TCP can be selected and configured in Edit -> Options, Packet. We have some more detailed instructions on configuring for TCP here:

http://www.nessoft.com/kb/51

You can configure the port for TCP - I'm not sure how port 40 is relevant, but maybe they can fill you in on this.

For more information on port use for the different protocols, see:

http://www.nessoft.com/kb/41

I think it's actually the returning packets that are causing problems, and all protocols use the same returning packets for intermediate hops (which is what you're having problems with) - ICMP TTL expired in transit type 8 sub-type 0. Unless the Actiontec bug is in the way it correlates outgoing packets with returning packets (which is possible), then I'm not sure that changing packet types will help.

At least they're talking to you - that's a good start! Please keep us apprised of the situation.

- Pete