kris 332e8aa176 (The last paragraph of this message has an implementation re-work suggestion) ...

o Fixed host discovery probe matching when looking at the returned TCP data in
  an ICMP error message.  This could lead to incorrectly discarded responses
  and the debugging error message: "Bogus trynum or sequence number in ICMP
  error message" [Kris]

Fyodor was getting the error message "Got ICMP error with a TCP header that was
too short" while scanning, and looked at the code to see a comment I made about
requiring 12 bytes of TCP data in an ICMP error message instead of the minimum
RFC requirement of 8 bytes.

I made this comment and requirement because tcp_trynum_pingseq_decode() was
being called on the TCP data, and was using the ACK field (which is just past
the 8 byte range).  However, upon further inspection, we came to the conclusion
that this code was broken because examining the ACK field should only be done
on a TCP response, not on our own probe (which is what we're looking at in the
ICMP data).

This assumes that -g is used (the only reason that the SEQ/ACK is checked since
the source port number is used otherwise), but the code is also broken without
it because the *_decode() function checks the destination port number rather
than the source port (which should be checked since it's our own probe we're
looking at).

So I've removed the 12-byte requirement and pingseq checking calls, and just
check that the received SEQ number matches the probe SEQ number.


Should we just work with the SEQ/ACK matching when using TCP and leave the
pingseq/trynum port number encoding to UDP?  This means behavior won't change
with the use of -g, and it should be guaranteed to be there since we'll only
be looking at whole TCP headers rather than any smaller chunks.  Plus, the SEQ
number is already getting encoded with the pingseq/trynum info, we're just not
decoding the ACK responses unless -g is used.

2008-07-26 00:25:24 +00:00

195 KiB

Raw Blame History

View Raw