Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Jun 1995 14:35:07 -0400
From:      Randall Becker <datads!becker@uunet.ca>
To:        hackers@freebsd.org
Subject:   Re: I call it the "NT sniper bug".
Message-ID:  <9506051435.aa19776@vulcan.datadesign.com>
In-Reply-To: <199506041413.OAA00764@fathergoose.net6c.io.org>; from "Ken Wong" at Jun 4, 95 10:13 am

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Hope this helps,

Regards,

Randy

> From owner-freebsd-hackers@freefall.cdrom.com Sat Jun  3 23:39:56 1995
> Message-Id: <m0sHKi9-0003viC@TFS.COM>
> From: julian@TFS.COM (Julian Elischer)
> Subject: I call it the "NT sniper bug". (fwd)
> To: hackers@freebsd.org
> Date: Thu, 1 Jun 1995 17:35:37 -0700 (PDT)
> X-Mailer: ELM [version 2.4 PL23]
> Content-Type: text
> Content-Length: 3856      
> Sender: hackers-owner@freebsd.org
> Precedence: bulk
> 
> Just say no..
> I'm sure we might all bare this one in mind
> 
> I bet we'll hear about it sometime
> 
> 
> > 
> > Date: Mon, 29 May 1995 15:05:06 -0400
> > Forwarded-by: bostic@CS.Berkeley.EDU (Keith Bostic)
> > Subject: I call it the "NT sniper bug".
> > 
> > Forwarded-by: matthew green <mrg@mame.mu.OZ.AU>
> > Forwarded-by: Richard Michael Todd <rmtodd@independence.ecn.uoknor.edu>
> > Forwarded-by: randy@ux1.cso.uiuc.edu (Randall E. Cotton)
> > 
> > langner@seufert.de (Ernst Langner) writes:
> > 
> > > In our network I've sometimes seen the ICMP Message "host unreachable".
> > > It was generated by a PC running Windows NT 3.5. There was trafic between
> > > two stations e.g. two sun workstations.  The NT PC sends the ICMP message
> > > to one of the sun stations unmotivated.  Such messages are normaly
> > > generated by gateways, I can't find any reason for a station in a LAN
> > > environment to generate such a message. It seems to be a bug.  The sun
> > > workstation ignores this ICMP message. But we are using some X terminals
> > > too. They believe what the message says and break down a session.
> > 
> > YES, YES, YES!
> > 
> > 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.
> > 
> > After travelling to the other building, tracking down the offending
> > machine and seeing that all it was running was NT, I didn't even
> > believe my eyes at first ("gotta be an IP address conflict", I said to
> > myself, "something else has got to be the culprit"). But thorough
> > testing (again, with a Sniffer) prooved it beyond any doubt...
> > 
> > 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.
> > 
> > This bug is truly subtle and insidious. It's as if NT, disguised as an
> > innocent user-friendly operating system, is surreptitiously playing
> > "network sniper", firing off single-packet shots that can trash
> > arbitrary TCP connections present on or passing through the immediately
> > attached net.  I bet most people that have it don't even know it.
> > 
> > By the way, the reason why it must be a bug is threefold:
> > 
> > First of all, NT shouldn't even be *aware* of traffic that isn't
> > addressed to it. 
> my own theory is that the host being shot at is brave enough to
> 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 :)
> 
> > Secondly, any such packet that errantly makes it to
> > NT's TCP/IP stack *should* be ignored by that stack. Thirdly, an NT
> > workstation, not being a router, absolutely should never send an ICMP
> > host unreachable packet. Pretty hoarked, if you ask me.
> > 
> > If anyone else has seen this behavior, please send me e-mail, or better
> > yet, reply to the group - it may be of wide interest. I'd like to band
> > together, if possible, to figure out a solution - dealing with MS Tech
> > Support on this is not exactly high on my list of strategies.
> > 
> > Randall Cotton
> > Network Analyst
> > University of Illinois
> > Network Administrator Support
> > 
> 
> 


-- 
----------------------------------------------------------------------------
Randall Becker                                         Voice: (905) 677-6666
Data Design Systems Inc.                        EMail: becker@datadesign.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506051435.aa19776>