[1284] in Athena Bugs
comp.bugs.4bsd: Re: Serious IBM 4.3 network bug
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Oct 31 02:42:59 1988
Date: Mon, 31 Oct 88 02:42:39 EST
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU, don@ATHENA.MIT.EDU
In-Reply-To: [1216] in Athena Bugs
[0070] daemon@ATHENA.MIT.EDU 4.3_BSD_bugs 10/30/88 00:05 (87 lines)
Subject: Re: Serious IBM 4.3 network bug
From daemon@BLOOM-BEACON.MIT.EDU Sat Oct 29 23:05:25 1988
Received: by MENELAUS.MIT.EDU (5.45/4.7) id AA17230; Sat, 29 Oct 88 23:05:25 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01951; Sun, 30 Oct 88 00:06:40 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA02001@BLOOM-BEACON.MIT.EDU>; Sun, 30 Oct 88 00:04:36 EDT
Path: bloom-beacon!apple!bionet!agate!labrea!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!enea!kth!draken!chalmers!ce.chalmers.se!afs!ostholm
From: ostholm@ce.chalmers.se (Stig Ostholm)
Newsgroups: comp.dcom.lans,comp.sys.ibm.pc.rt,comp.bugs.4bsd
Subject: Re: Serious IBM 4.3 network bug
Keywords: IBM network bug, DEC LANbridge
Message-Id: <246@cert1.ce.chalmers.se>
Date: 26 Oct 88 11:10:19 GMT
References: <23657@pprg.unm.edu>
Organization: Chalmers Univ. of Technology, Gothenburg, Sweden
Lines: 71
Apparently-To: 4bsd-bugs-mtg@menelaus.LOCAL@athena.mit.edu
In article <23657@pprg.unm.edu> cyrus@pprg.unm.edu (Tait Cyrus) writes:
>
>There has been A LOT of talk lately concerning DEC LANBridges learning
>ff-ff-ff-ff-ff-ff (the broadcast address). Well, as I posted a few
>days ago, I thought that I saw a relation between seeing these packets
>and an IBM PC/RT booting.
.
.
We at Chalmers University of technology has also experiensed this behavior
and made the following observations:
* Both the Miniroot diskett and the "normal" kernel sends garbage.
* This bug is also present in ibm4.3 release 2
* The bug is NOT present in AIX.
We have also made a fix to the kernel that makes all garbage packages to be
"controlled" (it sends "IBM RT/PC" from itself to itself).
The real cause of this behavior is currently unknown.
The fix in /usr/sys/caif/if_un.c:
2c2
< * 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1986,1987
---
> * 5799-CGZ (C) COPYRIGHT IBM CORPORATION 1986,1987
6c6
< /* $Header: if_un.c,v 1.1 88/05/19 09:59:24 ostholm Exp $ */
---
> /* $Header: if_un.c,v 1.2 88/05/20 10:24:38 ostholm Exp $ */
11c11
< static char *rcsid = "$Header: if_un.c,v 1.1 88/05/19 09:59:24 ostholm Exp $";
---
> static char *rcsid = "$Header: if_un.c,v 1.2 88/05/20 10:24:38 ostholm Exp $";
120a121,125
> /*
> * The next line puts the transmitter in loopbackmode so that no
> * uncontrolled packeges are sent on the ethernet.
> MM_OUT(&addr->un_edlc.tmode, TM_NORMAL - TM_LBC);
> */
124a130,133
> /*
> * The next line puts the transmitter in normal mode.
> MM_OUT(&addr->un_edlc.tmode, TM_NORMAL);
> */
876a886
> register int i;
879d888
< MM_OUT(&addr->un_edlc.reset, RESET_ON);
880a890,909
> MM_OUT(&addr->un_edlc.reset, RESET_ON);
> /*
> * Set the Xmit-buffer area to a know value
> */
> #define DUMMY_MSG "IBM RT/PC"
> #define MSG_LEN ((sizeof DUMMY_MSG)-1)
> i = UN_XBSIZE - MSG_LEN;
> /* Set the dummy message */
> bcopyout(DUMMY_MSG, &addr->un_xmtbuf[0][i],MSG_LEN);
> /* set protocol type 0 (IEEE package, illegal) */
> i--, MM_OUT(&addr->un_xmtbuf[0][i], 0x00);
> i--, MM_OUT(&addr->un_xmtbuf[0][i], 0x00);
> /* source and destination address = this card */
> i -= ETH_ADDR_SIZE;
> bcopyout(&addr->un_eprom[UN_EADDROFF], &addr->un_xmtbuf[0][i],ETH_ADDR_SIZE);
> i -= ETH_ADDR_SIZE;
> bcopyout(&addr->un_eprom[UN_EADDROFF], &addr->un_xmtbuf[0][i],ETH_ADDR_SIZE);
> /* Set the tx-start registers */
> MM_OUT(&addr->un_xsar[1], i & 0xFF);
> MM_OUT(&addr->un_xsar[0], i >> 8 & 0xF);
--[0070]--
