non-ICMP traceroute programs

[Sparda]

Dose any body know of any programs that can performe trace routes but allow you to use other protocolls? I'm specificly looking for one that will performae a trace router with the http protocol

[cooper]

I believe the way traceroute works is you send a packet to a remote host with a really short TTL (Time To Live) value. The ICMP message you get back is to tell you your packet reached its TTL before it reached its destination. You then take note of the machine who said that, increase the TTL by 1 and send the packet again.

I don't think the packet you send out _has_ to be an ICMP packet itself, but I don't know for certain.

[cooper]

And of course, Wikipedia is your friend. :P

[Sparda]

Correct cooper, I am wanting to test POSSIBLE incomming protocall blocking. A normal traceroute (ICMP all the way) is succesfull. However, http traffic seems to have difficulty getting though if at all. Hence forth I need a program that can perfrom traceroutes using the http protocal.

[Sparda]

From what I can tell such a program hasn't been writen, some one should write one. I don't have the technical ability, but I know the concept:

The program has to generate standred http requests ith incrimenting TTL, it's that simple, except it isn't. This causes a NAT transversal problem.

While with a normal tracerouter you send ICMP requests, so the NAT router expects to receive a ICMP replie. However, using http as the 'initial' protocall means the NAT router doesn't expect a ICMP replie and so will block it. As such all of the traceroute responces will fail. The only way I can see around this is to tell your router to farward all ICMP packets to your computers internal IP address or, as a last resort, point the DMZ at your computer.

[cooper]

tcptraceroute HTMLized manual page

Make it send out a packet to a remote host, port 80.

The program has to generate standred http requests ith incrimenting TTL, it's that simple, except it isn't. This causes a NAT transversal problem.

You might want to explain that one, as I don't see where the NAT traversal problem lies.

When you connect out to the remote machine, you end up with a tcp socket between you and the remote host. With NAT in the middle if you use that.

You then send a packet over this tcp socket with ever increasing TTL values. As long as it's the same socket, things will work fine.

[Sparda]

The problem lies in that sending a http request requiers a destination and a source port. With ICMP packets you can't and don't specifiy a port. So while the router will be expecting a server responce on say port 21465, it actualy recives an ICMP packet, and thinks "wait a minuet, I wasn't expecting this" and drop the packet. Or do modern NAT routers combate this by farwarding ICMP packets that are recived from a recently requested source to where the request came from?

[cooper]

Would you please READ that link and try again?

[Sparda]

You know I don't read :P

Any way, thats usfull for testing port blocking, but it dosen't use the http protocol.

[cooper]

Damn, I figured you knew all this already.

When you want a traceroute, you send out 'a' packet. To mimic HTTP you would make that a TCP packet, destined for port 80.

You should remember that HTTP runs *over* TCP (which in turn runs over IP, hence TCP/IP). A single HTTP request might very well span multiple TCP packets. And a traceroute works by getting a single packet rejected due to its age before it reaches its endpoint. The data in the packet is irrelevant. Unless you want your packet to go through an HTTP proxy, but then that proxy will create its own packet(s) once it has received your full request. It will not copy over the TTL field from your packets to the ones it will send out, rendering any tracerouting beyond it a futile experiment.