From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 01:59:53 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94C921065672; Wed, 4 Feb 2009 01:59:53 +0000 (UTC) (envelope-from jchambers@ucla.edu) Received: from out-21.smtp.ucla.edu (out-21.smtp.ucla.edu [169.232.47.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC228FC08; Wed, 4 Feb 2009 01:59:53 +0000 (UTC) (envelope-from jchambers@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.150]) by smtp-4.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id n141xZpI001283; Tue, 3 Feb 2009 17:59:35 -0800 Received: from computer.local ([149.142.36.207]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id n141xZhf001168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2009 17:59:35 -0800 Message-ID: <4988F687.4050105@ucla.edu> Date: Tue, 03 Feb 2009 17:59:35 -0800 From: Jason Chambers Organization: UCLA User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org References: <200902021344.n12DieCX021758@freefall.freebsd.org> In-Reply-To: <200902021344.n12DieCX021758@freefall.freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.244 Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2009 01:59:53 -0000 rwatson@FreeBSD.org wrote: > Thanks for your detailed bug report. It seems like a few things are going > on here, and probably need to be diagnosed individaully. First, the error > reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only > be triggered in the following kernel code: (...) > > This suggests that Nessus is passing an unexpectedly high or low number > of usec's, and is therefore probably an application bug. Thanks for pointing this out. Although unrelated to the issue at hand it possibly impacts nessus results and will help push their support team in the right direction. I see this error on a FreeBSD system that successfully runs scans. > > In general, "Network is unreachable" (ENETUNREACH) is generated by protocol > sockets when the destination host is on a non-local network and the gateway > specified in the route to the host is unreachable -- for example, ARP can't > find the gateway, the device link is down, etc. > > Is there any indication in the system logs of the link state going up and > down? You can use "route -n monitor" to track some of the relevant events. > Given that you've tried multiple cards, I can't help but wondering if > there is a cabling, switch, or router problem, so if you haven't already, > I'd follow those possible lines of diagnosis as well. There's no indication of interface flapping in the logs and I checked that the underlying infrastructure is fine. Route -n monitor shows nothing before and during the NMap or Nessus scanning. I suspect it's hardware related because not all FreeBSD (7.1-p2) systems I'm using have the problem. The commonality in all of it is newer Dell rack server systems ( 8-core PowerEdge 1950 and SC1435's). This "Network is unreachable" error seems to always occur with NMAP's OS discovery phase. ex: nmap -sS -p 22 -O host However, only on the SC1435's does Nessus fail to run successfully. When I say run, I mean the nessus process successfully sends out probe traffic (verified at the remote destination) but ignores the replies. Tcpdump shows that they arrive fine. The only thing different about these SC1435's from other systems is a patch I've applied to have the ServerWorks HT1000 controller work. (ata_ht1000.patch) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-10/msg00039.html I converted two of the servers to Linux and everything works fine with them. Rather than bury the problem I'd like to understand what fails. I can give access to one or both of these machines if it would help the effort. Otherwise, any suggestions on what tests I should run to further isolate this problem to a specific subsystem ? --Jason