Date: Tue, 16 Jun 1998 13:56:10 +0200 (MEST) From: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> To: freebsd-hackers@freefall.cdrom.com Subject: robustness against 'host unreachable packets' Message-ID: <199806161156.NAA04169@gilberto.physik.RWTH-Aachen.DE>
next in thread | raw e-mail | index | archive | help
I posted a message in -questions today about a problem had with
a FreeBSD (2.2.5) system acting as X server for a HP Mentor Graphics
application. The user was bugged by sporadic disruption of the X session
and since there were no outer signs of malfunction either the client
or the server I started a tcpdump yesterday evening logging
all pakets originating and destined to either hosts.
This morning my colleague called me up again telling it just
happened again. I looked into my logs and found that right at that
time the FreeBSD machine received a packet from a third host
which was looking like that:
8:28:03.151214 monk.6000 > hp.1327: P 151805:151837(32) ack 661157 win 17520 (
DF)
08:28:03.152081 arp who-has monk tell acc3df.physik.rwth-aachen.de
08:28:03.152336 arp reply monk is-at 0:40:95:24:d5:9b
08:28:03.152780 acc3df.physik.rwth-aachen.de > monk: icmp: host hp unreachable
08:28:03.163115 monk.6000 > hp.1327: P 151837:151869(32) ack 661157 win 17520 (
DF)
08:28:03.167881 hp.1327 > monk.6000: . ack 151869 win 7776
08:28:03.172922 monk.6000 > hp.1327: P 151869:151901(32) ack 661157 win 17520 (
DF)
Further investigation revealed that said host was happily firing
other icmp host unreachable packets to other hosts phantasizing
unreachable connections.
Well, the infamous 'NT sniper bug' came to mind. The host in question
was a Win3.11 host with probably a very old MS TCP/IP stack.
I was able to log a bunch of other icmp host unreachable packets
originating from that host. Since that host is out of reach of my
administration it seems hard to convince network
admin colleagues to take this host from the net and that this host
is doing something malign resp. beyond RFC or specs.
So I will put it here to discussion especially because earlier mail
I collected in '95 and '96 stated (Free)BSD being more immune against this
kind of malfunction put at present it looks like FreeBSD being especially
sensitive against these packets. At least they lead to immediate
disconnection of the X and rlogin session in that particular case.
I'm appending that old sniper bug emails again.
--
Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
|From owner-freebsd-hackers@freefall.cdrom.com Mon Jun 5 21:40:47 1995
|Received: from freefall.cdrom.com (freefall.cdrom.com [192.216.222.4]) by gilberto.physik.rwth-aachen.de (8.6.8/8.6.9) with ESMTP id VAA21988 for <kuku@gilberto.physik.RWTH-Aachen.DE>; Mon, 5 Jun 1995 21:40:45 +0200
|Received: from localhost (daemon@localhost)
| by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA23040
| ; Mon, 5 Jun 1995 12:27:44 -0700
|Received: (from majordom@localhost)
| by freefall.cdrom.com (8.6.10/8.6.6) id MAA23025
| for hackers-outgoing; Mon, 5 Jun 1995 12:27:41 -0700
|Received: from seraph.uunet.ca (uunet.ca [142.77.1.254])
| by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA23018
| for <hackers@freebsd.org>; Mon, 5 Jun 1995 12:27:39 -0700
|Received: from datads by mail.uunet.ca with UUCP id <173841-8>; Mon, 5 Jun 1995 15:29:23 -0400
|Subject: Re: I call it the "NT sniper bug".
|To: hackers@freebsd.org
|Date: Mon, 5 Jun 1995 14:35:07 -0400
|From: Randall Becker <datads!becker@uunet.ca>
|In-Reply-To: <199506041413.OAA00764@fathergoose.net6c.io.org>; from "Ken Wong" at Jun 4, 95 10:13 am
|X-Mailer: ELM [version 2.3 PL11]
|Message-ID: <9506051435.aa19776@vulcan.datadesign.com>
|Sender: hackers-owner@freebsd.org
|Precedence: bulk
|Status: OR
|
|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
|
|
|From owner-freebsd-current@freefall.freebsd.org Sat Jan 20 02:41:06 1996
|Received: from zit1.zit.th-darmstadt.de (zit1.zit.th-darmstadt.de [130.83.63.20]) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) with ESMTP id CAA05250 for <kuku@gilberto.physik.RWTH-Aachen.DE>; Sat, 20 Jan 1996 02:41:05 +0100
|Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [192.216.222.4]) by zit1.zit.th-darmstadt.de (8.6.12/8.6.9) with ESMTP id CAA14553; Sat, 20 Jan 1996 02:36:46 +0100
|Received: from localhost (daemon@localhost)
| by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17254
| Fri, 19 Jan 1996 13:55:41 -0800 (PST)
|Received: (from root@localhost)
| by freefall.freebsd.org (8.7.3/8.7.3) id NAA17188
| or current-outgoing; Fri, 19 Jan 1996 13:54:28 -0800 (PST)
|Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
| by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17181
| for <freebsd-current@FreeBSD.ORG>; Fri, 19 Jan 1996 13:54:23 -0800 (PST)
|Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA08703; Fri, 19 Jan 1996 14:45:14 -0700
|From: Terry Lambert <terry@lambert.org>
|Message-Id: <199601192145.OAA08703@phaeton.artisoft.com>
|Subject: Re: Windows TCP/IP interoperability?
|To: kuku@gilberto.physik.RWTH-Aachen.DE
|Date: Fri, 19 Jan 1996 14:45:14 -0700 (MST)
|Cc: terry@lambert.org, adam@veda.is, freebsd-current@FreeBSD.ORG
|In-Reply-To: <199601190821.JAA02867@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Jan 19, 96 09:20:59 am
|X-Mailer: ELM [version 2.4 PL24]
|MIME-Version: 1.0
|Content-Type: text/plain; charset=US-ASCII
|Content-Transfer-Encoding: 7bit
|Sender: owner-current@FreeBSD.ORG
|Precedence: bulk
|Status: OR
|
|> > There is also a known problem with Windows NT boxes illegally generating
|> > RIP packets and causing other hosts to dump. This is fixed in the
|> > latest release of NT, or a patch is available through MSN. Have you
|> > recently added an NT machine to a previously functional network?
|>
|>
|> Is this what has been reported a year ago (by Keith B.) as the so called
|> 'sniper bug' ?
|
|Yes.
|
|It's really a problem when you have an older MS/TCP listening to the
|bogus RIP broadcasts and using them to preeemptively dump connections.
|
|The problems are synergistic.
|
|
| Terry Lambert
| terry@lambert.org
|---
|Any opinions in this posting are my own and not those of my present
|or previous employers.
|
|From owner-freebsd-questions@freefall.freebsd.org Tue Jun 18 01:55:11 1996
|Received: from sel1.zit.th-darmstadt.de (sel1.zit.th-darmstadt.de [130.83.63.11]) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) with ESMTP id BAA08024 for <kuku@gilberto.physik.RWTH-Aachen.DE>; Tue, 18 Jun 1996 01:55:10 +0200
|Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.4]) by sel1.zit.th-darmstadt.de (8.7.1/8.6.9) with ESMTP id BAA09259; Tue, 18 Jun 1996 01:45:56 +0200 (MET DST)
|Received: from localhost (daemon@localhost)
| by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA07832;
| Mon, 17 Jun 1996 16:08:26 -0700 (PDT)
|Received: (from root@localhost)
| by freefall.freebsd.org (8.7.5/8.7.3) id QAA07819
| for questions-outgoing; Mon, 17 Jun 1996 16:08:24 -0700 (PDT)
|Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
| by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA07803
| for <questions@freebsd.org>; Mon, 17 Jun 1996 16:08:13 -0700 (PDT)
|Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA08975; Mon, 17 Jun 1996 16:06:06 -0700
|From: Terry Lambert <terry@lambert.org>
|Message-Id: <199606172306.QAA08975@phaeton.artisoft.com>
|Subject: Re: Rlogin delay
|To: brian@MediaCity.com
|Date: Mon, 17 Jun 1996 16:06:06 -0700 (MST)
|Cc: terry@lambert.org, questions@freebsd.org
|In-Reply-To: <199606172243.PAA21939@MediaCity.com> from "Brian Litzinger" at Jun 17, 96 03:43:51 pm
|X-Mailer: ELM [version 2.4 PL24]
|MIME-Version: 1.0
|Content-Type: text/plain; charset=US-ASCII
|Content-Transfer-Encoding: 7bit
|Sender: owner-questions@freebsd.org
|X-Loop: FreeBSD.org
|Precedence: bulk
|Status: RO
|
|> > > I've observed something concerning rlogin that is a bit odd to me, and
|> > > increasingly annoying for my users. When a user logs off and then tries
|> > > to re-log within a reasonable delay from another machine on the local
|> > > network, the login will be ingored for a very long time (10-60 seconds
|> > > seems typical). I checked the /etc/inetd.conf to make sure it was okay:
|>
|> I've observed the following behavior between two FreeBSD of every
|> version since 2.0.5
|>
|> freebsd1# rsh freebsd2 ls -a
|> ./ .cshrc .klogin .rhosts
|> ../ .fvwmrc .login .xsession
|> .Xdefaults .history .profile
|>
|> freebsd1# rsh freebsd2 ls -a
|> (30 or so seconds later)
|> Connection refused
|
|Interesting.
|
|Did you know that FreeBSD and Linux handle route errors differently,
|and that maybe a timeout on disconnect is being misinterpreted?
|
|Linux drops the connection (making it somewhat succeptible to the
|"NT sniper bug", actually), and FreeBSD retries.
|
|Matt Day posted something about this to -hackers or to -current
|a while ago.
|
|If you are stuck in an incremental back-off, it could explain a few
|things.
|
|It would also explain why the change came in at the same time as the
|4.4 Lite code came in in place of the 4.3 (Net/2) code.
|
|
| Terry Lambert
| terry@lambert.org
|---
|Any opinions in this posting are my own and not those of my present
|or previous employers.
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806161156.NAA04169>