From owner-freebsd-hackers Mon Jun 5 19:37:52 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA21825 for hackers-outgoing; Mon, 5 Jun 1995 19:37:52 -0700 Received: from wc.cdrom.com (wc.cdrom.com [192.216.223.37]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA21819 for ; Mon, 5 Jun 1995 19:37:48 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by wc.cdrom.com (8.6.12/8.6.12) with ESMTP id TAA23831 for ; Mon, 5 Jun 1995 19:37:48 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA05475; Tue, 6 Jun 1995 12:24:16 +0930 From: Michael Smith Message-Id: <199506060254.MAA05475@genesis.atrad.adelaide.edu.au> Subject: Re: I call it the "NT sniper bug". To: datads!becker@uunet.ca (Randall Becker) Date: Tue, 6 Jun 1995 12:24:15 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <9506051435.aa19776@vulcan.datadesign.com> from "Randall Becker" at Jun 5, 95 02:35:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2873 Sender: hackers-owner@freebsd.org Precedence: bulk Randall Becker stands accused of saying: > > It sounds to me like the problem is at a really really low level in the > NT TCP/IP stack where packets not destined for the NT are somehow being > passed (i.e. the destination MAC address is being ignored and all packets > are being processed by the NT stack). As the packets are passed up the > stack, they will be recognized as not being for the NT's IP address. The > routing table will be consulted (as it would for, say, the loop-back), and > since the NT is not acting as a router (i.e., no appropriate routing > table entries), the message will generate the experienced ICMP host > unreachable messages. This is, of course, total crap. (no offense intended). 1) The ethernet card shouldn't be in promiscuous mode. It requires a conscious effort to set it in the first place, so it's not 'accidentally' happening. 2) As the NT box is not a router, it should _never_ be sending back NRTH ICMP replies. Read the RFC. If the NT box is really doing what was described, then it's intentional; you don't build a perfectly-formed NRTH by 'accident'. > Randy >>> I just recently saw this here at University of Illinois, Urbana/Champaign. >>> I call it the "NT sniper bug". A UNIX software distribution process >>> between subnets in different buildings was consistently and inexplicably >>> failing at what appeared to be random times. Analysis of the traffic >>> (Network General Sniffer) showed the cut connections were due to an ICMP >>> type 3 (Destination Unreachable) code 1 (Host Unreachable) packet. >>> According to the ICMP spec (RFC792), such packets may only be sent from >>> routers. I assumed the source was indeed a router and perhaps there was >>> a problem with the network in the other building. When I learned it was >>> a PC, I was intrigued to say the least. >>> ... >>> Every once in a while at what appeared to be random intervals, this >>> machine was choosing an apparently arbitrary IP packet on the Ethernet >>> (regardless of its addressed destination) and generating an ICMP host >>> unreachable error packet to its source, dutifully including the first >>> portion of the victim packet. >>> >> have sent out a 'arp request' as it's own arp table entry >> for the other machine had just timed out... [JRE] >> hmm wonder if uSoft want to make all other machines appear unreliable :) I'd have to agree there, Julian 8) > Randall Becker Voice: (905) 677-6666 -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" - Terry Lambert [[