From owner-freebsd-net@FreeBSD.ORG Wed Feb 4 02:00:13 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C45981065673 for ; Wed, 4 Feb 2009 02:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B0C448FC13 for ; Wed, 4 Feb 2009 02:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n14203BG015374 for ; Wed, 4 Feb 2009 02:00:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n14203lg015373; Wed, 4 Feb 2009 02:00:03 GMT (envelope-from gnats) Date: Wed, 4 Feb 2009 02:00:03 GMT Message-Id: <200902040200.n14203lg015373@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jason Chambers 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 Reply-To: Jason Chambers 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 02:00:14 -0000 The following reply was made to PR kern/130605; it has been noted by GNATS. From: Jason Chambers To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Date: Tue, 03 Feb 2009 17:59:35 -0800 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