Cannot scan the local network

[bortzmeyer]

If I give to scan6 -d the prefix of the local network, I get an unclear message:

% sudo scan6 -d 2001:db8:3:8bb0::/64 -i eth1 -e print-global Error while performing Neighbor Discovery for the Destination Address Error while learning Souce Address and Next Hop

OK, I can use -L instead but -d is useful to detect some machines, which do not reply to -L tricks, and, anyway, the error message is very poor.

[fgont]

Agreed that the error message is poor -- will fix this (I seem to recall that we were trying to catch this scenario, suggesting to use the -L option). The reason why the current version doesn't support this is that right now the scanner sends the probes in parallel, and prints them as soon as they receive -- since the "next hop" is always the same router (and hence you do not need to do neighbor discovery for each packet you send). If you want to do this sort of scan on the local network, we cannot really send the probes in parallel, because before sending each probe, we have to to ND for the corresponding destination, And if the destination is not there, we might need to timeout ND in, say, 1 or a few seconds. --- we could also try to do ND in paralel, but that would mean a more radical change of the structue of the scanner.

mmm.. maybe providing a "slow" option for this is better than nothing?

P.S.: Just our of curiosity: which nodes do not respond to our multicasted probes?

[fgont]

Stephane,

Doing the relevant administrativia... Please take a look at my earlier response, and let me know what you think.

Thanks! Fernando

[bortzmeyer]

No strong opinion about how to implement the scan. But if -d is not supported for the local network; the error message should be better "Use -L instead", for instance.

[fgont]

FWIW, --current delas with this as follows: Rather than defaulting to multicast probes, or trying to send the unicast probes directly on the local link, scan6 will send all packet probes to the local router, which will then send the probe packets back on the local link. There are a number of possible issues here:

1. If the router starts address resolution but also discards the packet that triggered address resolution, the address scan will be unreliable.
2. The router will send ICMPv6 redirects back to the attacker (the node running scan6). HOwever, since these are normally rate-limited, this will not be an issue.

In a net revision, I will also include the possibility to do address scans for local addresses simply based on ND echanges: i.e., send a Neighbor Solicitation for the target address, and if you receive a corresponding NA, consider that the address is up.