Re: ACK is being sent with a sequence of 0 every time.

[David Fifield <david () bamsoftware com>]

On Wed, Jun 13, 2012 at 12:47:32PM -0700, David Fifield wrote:
> This goes along with another long comment in tcp_probe_match:
>
>     /* We are looking to recover the tryno and pingseq of the probe, which are
>        encoded in the ACK field for probes with the ACK flag set and in the SEQ
>        field for all other probes. According to RFC 793, section 3.9, under
>        "SEGMENT ARRIVES", it's supposed to work like this: If our probe had ACK
>        set, our ACK number is reflected in the response's SEQ field. If our
>        probe had SYN or FIN set (and not ACK), then our SEQ is one less than the
>        returned ACK value because SYN and FIN consume a sequence number (section
>        3.3). Otherwise, our SEQ is the returned ACK.
>
>        However, nmap-os-db shows that these assumptions can't be relied on, so
>        we try all three possibilities for each probe. */

If I were you, I would experiment with the matching condition in
tcp_probe_match.

  if (o.magic_port_set) {
    goodseq = seq32_decode(USI, ntohl(tcp->th_ack) - 1, &tryno, &pingseq)
              || seq32_decode(USI, ntohl(tcp->th_ack), &tryno, &pingseq)
              || seq32_decode(USI, ntohl(tcp->th_seq), &tryno, &pingseq);
  } else {
    /* Get the values from the destination port (our source port). */
    sport_decode(USI, o.magic_port, ntohs(tcp->th_dport), &tryno, &pingseq);
    goodseq = true;
  }

Step through that carefully in a debugger, because this is where your
ACK reply is getting matched up with a SYN probe and vice versa. In the
case when o.magic_port_set is false, it appears that we don't do any
enforcement of matching SEQ and ACK values; what happens if you try
enforcing that?

As a related, simple test: See if you can reproduce the spurious closed
port issue when you use the -g option (which sets o.magic_port_set to
true).

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/