If it's working through the first two hops, that indicates that the "block" is either at hop 3, in between hop 2 and hop 3, or possibly at the inbound side of hop 2.

There are a number of reasons why there might be a difference.

First, PingPlotter's ICMP.DLL implementation uses the same API that the windows TraceRT uses, but the other methods do not. The UDP engine creates raw UDP packets, while the TCP engine either uses raw sockets in Windows, or it uses the WinPCap library (2.59 betas or newer required for TCP, of course).

All engine types, though, use the same packet size and packet contents. It could be that the router at hop 2 or hop 3 is specifically blocking certain types of packets, or packets with certain contents. It's a bit challenging to know for sure what the problem is, though.

One of the best ways to troubleshoot why one tool is working (ie: HyperTrace) and others not (ie: TraceRT) is to examine the packet contents with a network sniffer (like Ethereal) and then to configure the tools to send the same kinds of packets. If you know how the packet sizes are determined, you can also try and change the packet size on one tool to match the packet size on the other tool (although it may be the packet contents or cargo that's actually triggering things), rather than the packet size.

We've also seen some routers have problems with simultaneous packets - from the same program, or different programs at the same time. One of our inhouse DSL test routers - a Cisco 678 - exhibits oddities when multiple programs are tracing to the same destination.

It would be nice if this was just an easy "do this" problem, but it's probably not. Try changing the packet size of PingPlotter to something smaller (the listed minimum, for example), and see if that fixes it - that's the easiest thing to try. This is 28 bytes for ICMP or UDP packets, and 40 bytes for TCP packets.

Let us know what you find!

- Pete