Hi,
According to my tests, analysis and reading parts of the code, this
bug is not stricto sensu an overflow. What happens is that
host->num_out becomes negative (when read as a signed int, instead of
as an unsigned int), truly negative (not through overflow, but through
subtracting 1 to 0). That is because the ICMP_TIMXCEED for one host
gets accounted as an ICMP_TIMXCEED for another host when one runs
netselect over more than 256 hosts, and every ICMP_TIMXCEED decrements
host->num_out. Why 256? Because around line 299 of netselect.c, one
does:
host->seq = ++seq;
seq %= 256;
thus more than one host share the same seq (and thus UDP port number
for probes), but the packet_ok function relies solely on the UDP port
number to identify what host an ICMP packet is about. Hence, the ICMP
packet for one host gets accounted for another host, corrupting the
gathered statistics.
The negative scores are only a particularly noticeable specific case
of corruption, other scores may be corrupted in a less noticeable
way.
I see several solutions:
- don't limit seq to any particular ceiling. I must admit I don't
know why it was limited to 256 in the first place.
- actually look at hip->ip_dst to match ICMP packets with hosts in
packet_ok; this one seems more robust to me.
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
