distrib > Mageia > cauldron > i586 > by-pkgid > cef9461d8d9fff937f6554e18011f996 > files > 8


## $Id: TODO,v 2006/07/08 16:31:44 dave Exp $

Optimised Trace
	When a valid response is received and the probe is not the first in
	the list, swap the current probe with the first probe.  This works
	on the assumption that if probe 1 is blocked at this hop but probe 2
	gets through, the situation will probably be the same at the next

	If the sucessfull probe is inserted into at the start of the probe
	list, the whole trace will favour probes known to be successfull...

Fast trace
	When doing a multi-probe trace, don't wait for the individual probes
	to timeout, just send them all immediatly (might need a short
	delay).  Both packet sending and packet matching code will need to
	be rewritten to support this.

Probe Defaults
	if no type is specified after a probe type flag (e.g. just "-T" is
	on the command line) use a default type (e.g TCP defaults to port
	80, ICMP defaults to echo, etc).  GNU getop_long doesn't really
	allow this to be done without sacrificing how the command line
	options are procesed.  (when an option is flagged as arguments
	optional, arguments have to be specified as "-T=80", which sucks...)

Protocol trace probably doesn't work
	Need some method of testing this.  But it should already be better
	than that other *trace tool wot I wrote, that had a big /* FIXME! */
	comment in the protocol processing code, etrace assumes any response
	on the protocol that it's attempting to trace is good.

	It also might be a good idea to correctly process the ICMP Protocol
	Unreachable error.  At the moment the a Protocol ends when etrace
	receives an ICMP Protocol Unreachable error.  (Which gives the
	correct result, it would just be nice to do it correctly)

Add all the insane packet construction flags
	It's scares people who read the man page that every letter of the
	alphabet does *something*, and nobody really uses any of them, but
	what the hey...

Fix ARP handling.
	I've had to add "and not arp" to the PCap filter because arp
	requests (especially when spoofing traces from another address) were
	breaking things.  This should not break etrace since ARP should not
	be part of a trace, but the code should be corrected at some point
	because this is a pretty naff solution...

	UberFix: Handle the ARP responses from etrace