Date: Tue, 6 Jun 1995 12:24:15 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: datads!becker@uunet.ca (Randall Becker) Cc: hackers@freebsd.org Subject: Re: I call it the "NT sniper bug". Message-ID: <199506060254.MAA05475@genesis.atrad.adelaide.edu.au> In-Reply-To: <9506051435.aa19776@vulcan.datadesign.com> from "Randall Becker" at Jun 5, 95 02:35:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506060254.MAA05475>