From owner-freebsd-net@FreeBSD.ORG Wed Jan 22 17:03:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7453CF6 for ; Wed, 22 Jan 2014 17:03:40 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C32E1D56 for ; Wed, 22 Jan 2014 17:03:39 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wm4so737377obc.27 for ; Wed, 22 Jan 2014 09:03:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2/6WHfRmk+uKNGQxoN6p3CvDLKyceBvvGeHu+THnDBE=; b=Trx2EfdO9sIrVtbPsTYzoGxb1SOfWCX9llQZxxTEs9OQldzkxmOayEhhSRBZn3cFwL WZ+DulPOhADEw9Gc+CRRlVpg45IQaloElY3TkQC4IOODI4vHOWQMzIF1Z8hbcGIuPNA+ eRbTyTAL6Wz234eF4hBPoV5bs4YXwQVVFkWIODwlXw6xIecv46I9/wD3vXZTz271pKYF auFV1lssaWlK+vSeTA16Mm7aKhhfb+rTI1k3xvpmcw4YR6nTuD6rZZGo6cqlHo3mC6iU D7eVC2gqx974cHlF1s7Isk56LZHgpIY0/okGzZGqdBvgKNVqPF4tUb32JrkWwJHTO1UX 0eHw== X-Gm-Message-State: ALoCoQmCAIWVMONK0b9x9m9N97k5XbTQMmragtzrGXAHbJUJnTJwwyUdoA0DB2G/sAdxHKmO4rpR MIME-Version: 1.0 X-Received: by 10.182.29.33 with SMTP id g1mr2166098obh.59.1390410219103; Wed, 22 Jan 2014 09:03:39 -0800 (PST) Received: by 10.76.197.9 with HTTP; Wed, 22 Jan 2014 09:03:38 -0800 (PST) In-Reply-To: References: Date: Wed, 22 Jan 2014 12:03:38 -0500 Message-ID: Subject: Fwd: nmap not moving on after getting reset packets From: Daniel Malament To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:03:40 -0000 In the course of trying to do some comprehensive scans at work, I discovered the following behavior: nmap on SOURCE: # nmap -Pn -sS -v -n --scan-delay 20ms -p 1-65535 TARGET Starting Nmap 6.25 ( http://nmap.org ) at 2014-01-21 15:18 EST Initiating SYN Stealth Scan at 15:18 Scanning TARGET [65535 ports] Discovered open port 443/tcp on TARGET Discovered open port 80/tcp on TARGET Increasing send delay for TARGET from 20 to 40 due to max_successful_tryno increase to 4 Increasing send delay for TARGET from 40 to 80 due to 11 out of 16 dropped probes since last increase. Increasing send delay for TARGET from 80 to 160 due to max_successful_tryno increase to 5 Increasing send delay for TARGET from 160 to 320 due to 11 out of 29 dropped probes since last increase. SYN Stealth Scan Timing: About 2.67% done; ETC: 15:37 (0:18:51 remaining) [ctrl-c] tcpdump on SOURCE: 13:28:36.188904 IP SOURCE.59292 > TARGET.46181: Flags [S], seq 936512329, win 1024, options [mss 1460], length 0 13:28:36.209829 IP TARGET.46181 > SOURCE.59292: Flags [R.], seq 0, ack 936512330, win 1024, length 0 13:28:36.349905 IP SOURCE.59293 > TARGET.46181: Flags [S], seq 936577864, win 1024, options [mss 1460], length 0 13:28:36.370895 IP TARGET.46181 > SOURCE.59293: Flags [R.], seq 0, ack 936577865, win 1024, length 0 13:28:36.511905 IP SOURCE.59294 > TARGET.46181: Flags [S], seq 936381259, win 1024, options [mss 1460], length 0 13:28:36.537232 IP TARGET.46181 > SOURCE.59294: Flags [R.], seq 0, ack 936381260, win 1024, length 0 13:28:36.673905 IP SOURCE.59295 > TARGET.46181: Flags [S], seq 936446794, win 1024, options [mss 1460], length 0 13:28:36.694258 IP TARGET.46181 > SOURCE.59295: Flags [R.], seq 0, ack 936446795, win 1024, length 0 I'm checking on the nmap lists to see if this is expected behavior, but is it possible that something in the network stack is eating these packets between tcpdump and nmap? This is Nmap 6.25 on FreeBSD 9.2. PS: Adding --max-rtt-timeout 600ms --max-scan-delay 600ms made no difference.