Re: icmp traceroute
Re: icmp traceroute
- Subject: Re: icmp traceroute
- From: "Peter Sichel" <email@hidden>
- Date: Fri, 25 Aug 2006 17:25:31 -0400
On 8/25/06, Dalton Hamilton wrote:
>To make a long story short, how can I determine if the reply is to my
>ECHO in the case of ICMP_TTL_EXPIRE replies?
I'm the developer of IPNetMonitorX which includes a fairly complete
trace route tool.
The trick is when you get an ICMP time limit exceeded response, it
includes the IP header and first 64-bits (8 bytes) of the triggering
datagram. It's up to you to put the unique identifying information you
need in those first 8 bytes of the original UDP probe or ICMP echo
request. In my case I define a unique 16 bit identifier for each thread
running the tool and a unique sequence number for each probe sent out.
I collect this information in a table and then match it against any ICMP
responses that come back.
More importantly, you need to use the SO_TIMESTAMP option to have the
kernel timestamp responses as they are received and read the ancillary
data to extract this information to get accurate timing information.
Another trick I use is to define a single ICMP listener thread that
notifies any registered listeners. Any ICMP packets received are
delivered to every listening ICMP socket which means the kernel needs to
schedule and wake up every listening thread. If a user is tracing
multiple destinations at the same time or has other tools running, the
overhead may become noticeable (depending on how fast you trace).
Finally, if you are tracing through a NAT box, the NAT box needs to
untranslate the source IP address in the triggering datagram to
determine who should receive the response. Since the packet may be
modified in multiple places and not all of it is returned, you cannot
assume the checksum field returned in the triggering datagram will match
the checksum originally generated. [I develop NAT code as well.]
Kind Regards,
- Peter Sichel
Sustainable Softworks
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden