Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/12/87)
SUN-SPOTS DIGEST Tuesday, 11 August 1987 Volume 5 : Issue 31
Today's Topics:
Ethernet problems induced by bogus ICMP Address Mask Reply (3)
rwhod not broadcasting on proper address
dsun on SunView
Adding a SCSI disk to a SUN-3/52
Re: VME - VME adapters for SUN
Re: File system problems
File server troubles
TCP/IP (terminal server) printing from Suns?
3.0+ driver for the Interphase 2181?
SUN-3/50 memory expansion?
ICS-100 AD/DA board on a SUN?
PIC tool or TeX tool?
MacPaint/PICT files --> Sun Raster/Icon formats: tools?
----------------------------------------------------------------------
Date: Fri, 07 Aug 87 22:04:44 EDT
From: Preston Mullen <mullen@nrl-css.arpa>
Subject: Ethernet problems induced by bogus ICMP Address Mask Reply
Here's a new one to add to the list of things that can induce broadcast
storms and other serious problems. It involves an unpleasant interaction
between SunOS 3.3 and 3.4 and Wollongong's WIN/VX software version 3.0.
(Ironically, this problem was noticed when the Suns and VAXes were
upgraded to what is generally considered to be better networking
software.)
When a diskless Sun 3 workstation running SunOS 3.3 or 3.4 boots, at some
point it sends out a broadcast ICMP Address Mask Request. This is in
accordance with RFC950; unfortunately, an incorrect reply from any machine
on the network can be accepted by the workstation, and some incorrect
masks can induce the workstation to start sending all packets as Ethernet
broadcasts, which instantly leads to a broadcast storm.
If this happens, the workstation will probably fail to finish booting
completely, usually stopping during the NFS mount with "RPC: not
registered" messages, but sometimes sooner. Also, the workstation may
itself then generate an incorrect reply (sent as an Ethernet broadcast) to
a subsequent ICMP Address Mask Request from some other machine, thus
spreading the virus. Other symptoms that may be observed include
extremely sluggish operation of diskless machines and "no carrier" and
"Ethernet jammed" notices from Suns (aside from those generated during
broadcast storms).
This happened here on a non-subnetted Class B network when the 3.0 release
of Wollongong's IP/TCP software was installed on two VAXes running VMS.
Both VAXes replied to a Sun's ICMP Address Mask Request with network masks
of 0000FFFF instead of the correct FFFF0000. The diskless Sun gullibly
swallowed this and began to encapsulate every IP packet in an Ethernet
broadcast packet. Even after we isolated our network from the offending
VAXes, any Sun in this state would respond with the bogus netmask to a
broadcast from another Sun and thus continue the problem.
The solution was to disconnect the offending VAXes from the network, halt
ALL the diskless Suns, then reboot them. After that, we could let the
VAXes back on the network, but it was not really safe since any diskless
Sun reboot would start the cycle over again.
The people who own the VAXes that started the problem have told me that
the problem is really in the Wollongong software (i.e., not a
configuration error) and is a holdover from some "broken 4.3bsd code".
Evidently there are also problems with setting the address mask. They
report that Wollongong has sent them a fix.
==> Potential users of Wollongong 3.0 software should get a fix from
Wollongong before running 3.0 on a network where a machine might broadcast
an ICMP address mask request.
==> Sun should make their networking code smarter. There is no way a
netmask of 0000FFFF could ever be valid, since it must include the normal
network part of the address as well as the subnet part. The Suns should
have ignored the faulty replies instead of being driven berserk by them.
I've reported this to Sun. The problem doesn't affect Suns running 3.2 or
earlier releases since those releases have no subnetting support.
It would probably be better if the diskless Sun did not broadcast the
Address Mask Request but instead sent it directly to the server. I think
that the request is broadcast after the ifconfig of the diskless Sun's
Ethernet interface (anyway, an "address mask set to FFFF0000" report
appears on the console quite a while before the problem shows itself). If
that is so, then it's not clear why an ICMP Address Mask Request needs to
be sent at all, since the network mask can be specified in the ifconfig in
the rc.boot file.
By the way, our class B network is partitioned by level 2 bridges (Digital
DEBETs). Needless to say, they passed every bad packet and broadcast
right through. (The VAXes were on the other side of a bridge from my
Suns.) Yep, I'll be moving my stuff behind an IP gateway now.
Many, many thanks to Van Jacobson for 'tcpdump', which proved instrumental
in tracking this down. I hope Sun will let Van release the source code
for tcpdump.
Preston Mullen
Computer Science and Systems Branch
Information Technology Division
Naval Research Laboratory
Washington DC 20375-5000
P.S. Why do diskless Sun workstations running SunOS 3.4 broadcast an
ARP request for IP address 0.0.60.216 very early in the boot
sequence? (The ARP packet asks that replies go to 0.0.60.216.)
This appears to be wired into the Sun networking software.
It's harmless enough, but it should not be there. Maybe
someone forgot to take out some debugging code.
------------------------------
Date: Sun, 9 Aug 87 08:02:44 EDT
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Subject: Re: Ethernet problems induced by bogus ICMP Address Mask Reply
I believe your ARP request for 0.0.60.216 is used during the boot
sequence, at a point when the Suns don't know their Internet address.
They seem to use their serial number as an address. You'll also find such
addressing in the routing tables in certain versions of SunOS. I suggest
that you take 60 * 256 + 216, and see if you don't have a Sun with that
serial number.
------------------------------
Date: Mon, 10 Aug 87 08:31:12 CDT
From: timk@newton.ncsa.uiuc.edu (Tim Krauskopf)
Subject: Re: Ethernet problems induced by bogus ICMP Address Mask Reply
We encountered the exact same problem (diagnosed with tcpdump) between our
diskless Sun 3/50 (SunOS 3.3) and a Vaxstation (TWG under VMS). The
icmpmask response from TWG is backwards.
Easy work-around while waiting for bug fixes from TWG:
Install the netmask parameter in the rc.boot files (ifconfig lines) of as
many diskless Suns as you feel like.
Each of the Suns with the mask installed will operate correctly.
For the rest of the machines, the russian roulette has much better odds:
When the ICMP request goes out, there are several Suns waiting to respond
and they are faster at responding than the VAXen. Whoever gets there first
wins.
Isn't this fun?
Tim Krauskopf
National Center for Supercomputing Applications
University of Illinois
timk%newton@uxc.cso.uiuc.edu
------------------------------
Date: Fri, 7 Aug 87 15:21:41 MDT
From: hi!kurt@hc.dspo.gov (Kurt Zeilenga)
Subject: rwhod not broadcasting on proper address
We are configuring our hosts (Release 3.4) like:
/etc/ifconfig ie0 sunhost netmask 255.255.248.0 broadcast 129.24.15.255 \
-trailers up
[[ That last bit was one line in the original message. --wnl ]]
where the address of the hostname would be something like:
129.24.13.3 sunhosts
We broadcast on the subnet address 129.24.8 on host all '1 (ie:
129.24.15.255) as configured above. This is to conform with Internet
Standards. On our Ultrix and 4.3BSD systems this works fine.
On our SUNs, in.routed seems to understand this, yet in.rwhod doesn't.
Rwho seems to ignore the broadcast address ifconfiged in. Do you have a
fix for this or have any suggests?
Also, if for some reason you want to have two logic IP networks on the
same ethernet cable and want your SUN (with two ie boards) to gateway you
have to muck with the ifconfig lines. The boards get their ethernet
address from the SUN ID prom, hence have the same address, and you get two
controllers at the same hardware address. Not good. To get around this
we did:
ifconfig ie1 02:20:20:20:20:20 gateway -trailer up
Works great.
- Kurt (zeilenga@hc.dspo.gov)
------------------------------
Date: Fri, 7 Aug 87 14:16:16 PDT
From: eggert@grand.sm.unisys.com (Paul Eggert)
Subject: dsun on SunView
In Sun-Spots v5n29 tamir@cs.ucla.edu (Yuval Tamir) asks whether anybody
has gotten the old dsun program to work under SunView. The following
fixes should get dsun.tool to work under Sun UNIX Release 3.4. We've
changed dsun.tool in other ways, so your line numbers may differ. Be sure
your dev.h file matches ditroff's; there seem to be different ones
floating around.
Surely something better than this should be available these days!
-- Paul Eggert (sdcrdcf!eggert@cam.unisys.com)
[[ The diff was too large to include in the digest. It is available via
anonymous FTP from "titan.rice.edu" as "sun-source/dsun.diff". We will
try to honor requests for individual mailings to those without direct
ARPANet access. --wnl ]]
------------------------------
Date: Wed, 8 Jul 87 15:51:15 EDT
From: Mark Mendell <mendell@turing.toronto.edu>
Subject: Adding a SCSI disk to a SUN-3/52
We wanted to add some disk space to our SUN-3/52, but found that Sun's
price of $5000 (CDN) for a 71 Meg disk to be a bit high. We decided to
put together our own disk. We bought a Priam 519 190 Meg disk ($3249
CDN), and an Adaptec 4000A disk controller ($181 CDN). A box and power
supply was purchased independently. We had to buy the 50 pin connectors
(one for the back of the shoebox, one for the controller) for the cost of
$50 CDN. We wired the cable ourselves. Total cost about $4000 CDN for 190
Meg disk (157 Meg formatted).
Caveats:
We originally bought an Adaptec 5500 disk controller, because it
supports four disks. It also supports the SCSI disconnect-reconnect
protocol. Unfortunately, Sun OS 3.3 doesn't support disconnect-reconnect
except on the SCSI tape drive. The disk couldn't be used from Unix with
that controller. The system would hang when accessing the disk as a block
device. Sun couldn't tell us if this would be fixed in Sun OS 4.0.
We used diag to format the new disk, but we were guessing on the
number of sectors per track. We originally tried 18 sectors/track, but it
didn't work, and the diag failed when trying to reformat at 17 sectors/
track. We had to take the disk to another system, and format with another
controller for a couple of tracks. Only then would diag let us re-format
at 17 sectors/track.
The new disk controller was set to SCSI address 1, and the new
drive was drive 0. The config line is:
disk sd1 at si0 drive 8 flags 0
------------------------------
Date: Wed, 5 Aug 87 10:37:39 +0200
From: sunuk!sunfra!rich@sun.com (Richard Saunders - Sun France Consulting)
Subject: Re: VME - VME adapters for SUN
A Swiss company makes a sophisticated VME multiple cage adapter called the
Vertical Bus System. Here is the address:
Creative Electronic Systems S.A.
Route du Pont-Butin 70
CH-1213 Petit-Lancy
Switzerland
Telephone (41) 2292 5745; ask for Francois-Henri Worm.
Good luck! Richard Saunders (Sun France Consulting).
------------------------------
Date: 6 Aug 87 02:33:37 GMT
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Subject: Re: File system problems
In response to kfl's problem with a trashed file system. It is of course
possible that 3.3 of SunOS has a set of bugs that causes all of the things
you heard to be true. We have experience only with 3.2. However it is
far more likely that the Sun rep you were talking to is very confused
about a number of issues. We have a number of Sun systems, and run out of
disk space from time to time. We have had no trouble with file systems
being messed up, except when there is an actual hardware problem with the
disk. (Of course that's not to say there are no other possible causes. I
trust that you have the partitions set up properly, and they aren't
overlapping or something?) What happens when the file system is 90% full
(this shows as 100% on df) is that new files can't be written. In some
cases, new files may be truncated. But this should not affect existing
files, nor the integrity of the file system. One could imagine situations
where every last disk block was used, and it was impossible to update some
directory. (Does anybody know whether this is possible?) But normally
Unix is set up so you can't go over 90% unless you are root, and this
should prevent any such thing from happening even if it were possible.
I've never heard of the file system being trashed by using too much memory
in a user program. I'm reluctant to say that no such bug is possible,
since I've seen many strange bugs in my time, but this doesn't sound like
a very likely one (unless perhaps your swap space overlaps one of your
file systems).
After you restore a level 0 dump, you should do a new level 0 dump, in
order to have a dump whose inode numbers agree with those actually on
disk. This is discussed in the man page for restore. But there is no way
that failure to do a dump will trash the file system. You certainly don't
want to do it to /dev/null, since the whole point of doing it is to get a
new dump tape. There is no rush. You should simply do the new level 0 at
the time you would normally do your next incremental.
------------------------------
Date: Thu 6 Aug 87 17:55:54 PDT
From: Doug Bryan <Bryan@sierra.stanford.edu>
Subject: File server troubles
We are having some serious problems with our file server and the Sun
techies seem to be of little help. Thus, I thought I would appeal to the
collective wisdom of net-land...
We are running a 3/180 file server with 3 Eagles (under OS 3.2). The
following clips from /usr/adm/messages show the problem:
Aug 6 03:06
panic: bad rmfree
syncing disks... 9 9 7 3 done
dumping to dev 301, offset 25880
dump succeeded
Rebooting Unix...
Aug 6 11:37
panic: bad rmfree
syncing disks... xy1e: read reset (lost interrupt) --
blk #85070, abs blk #85070
13 13 11 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done
dumping to dev 301, offset 25880
dump succeeded
Rebooting Unix...
Aug 6 12:53
panic: bad rmfree
syncing disks... mbrelse: MR == 0!!!
xy2c: read reset (lost interrupt) -- blk #132544, abs blk #132544
6 6 6 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 done
dumping to dev 301, offset 25880
dump succeeded
Rebooting Unix...
Aug 6 13:06
panic: bad rmfree
syncing disks... 10 10 9 6 6 6 6 6 6 6 6 6 6 6 6 6 xy0h: write reset
(lost interrupt) -- blk #29648, abs blk #692048
3 3 3 3 done
dumping to dev 301, offset 25880
dump succeeded
Rebooting Unix...
Aug 6 13:13
panic: bad rmfree
syncing disks... xy1e: read reset (lost interrupt) --
blk #102536, abs blk #102536
16 16 14 8 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 done
dumping to dev 301, offset 25880
dump succeeded
Rebooting Unix...
When all 3 disks are being accesses, the file server crashes. Because
of our user load, it has been crashing about once every hour. And, as
you would expect, this often results in fsck being run and files lost.
All Sun has to say about the problem is that it is a "known" problem
and will be fixed by vapor-ware (OS 3.4). My questions are:
- Does anyone else have a similar file server configuration?
If so, are you experiencing this kind of thing?
- What can I do until the vapor-ware materializes?
Tonight I'm going to remove one of the disks; then we will be running 2
Eagles, one per controller. Sun seems to think the problem only occurs
when there are 2 Eagles on one controller. Any other ideas? We plan to
buy another server, but that will take a while. An Eagle is a terrible
thing to waste.
doug
------------------------------
Date: Tue, 4 Aug 87 13:12 EDT
From: SIMON%M_SCRVX2%sdr.slb.com@relay.cs.net
Subject: TCP/IP (terminal server) printing from Suns?
How does one go about driving a printer through a terminal server running
TCP/IP? The boxes concerned are a Sun 3/180S file server, and a Bridge
CS/100 terminal server configured with TCP/IP software. I don't mind
whether a permanent TCP connection is maintained or whether a new
connection is formed for each print job.
Thanks,
Simon Barnes
simon%m_scr%sdr.slb.com@relay.cs.net
(I'll summarise any responses received directly).
[[ Please mail responses directly to him. I will send out a summary when
he provides me with one. --wnl ]]
------------------------------
Date: Tue, 4 Aug 87 13:11:21 MDT
From: donn@cs.utah.edu (Donn Seeley)
Subject: 3.0+ driver for the Interphase 2181?
At some time in the past, an Interphase 2181 disk controller was purchased
for our Sun-2s. We'd like to use this disk controller to create a Sun-2
disk server and thus produce a homogeneous Sun-2 cluster (which we can
safely ignore thereafter). Unfortunately no one verified at the time of
the purchase that Sun supported the 2181... It seems that the ip driver
in SunOS 3.2 only supports the older 2180 controller, although there are
indications in the source that someone did at least attempt to produce a
working 2181 driver. Interphase won't take the 2181 as a trade-in on
something better and doesn't have any suggestions about using it; no one
at Interphase whom we talked to appeared to remember that there was ever a
2181 product, which tells you something about turnover in the field...
If you have a driver for the 2181, or any constructive comments about what
to do with it, please send me mail...
Donn Seeley University of Utah CS Dept donn@cs.utah.edu
40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn
------------------------------
Date: 7 Aug 87 14:23:55 GMT
From: marantz@aramis.rutgers.edu (Roy Marantz)
Subject: SUN-3/50 memory expansion?
Does anyone know of a way to put more memory on a Sun-3/50. We have a
bunch of them and feel they could use more memory when running lisp (and
the like). Unfortunately we don't have enough money to trash them and buy
replacement machines (sun-3/60 or something). We'd like to add at least
4Mb and can probably afford around $2K per machine. Oh, I'm talking about
35, or so, units. I've talked with everyone at Sun that I can get hold of
and they don't seem to believe it can be done reliably. Anyone have any
ideas? I'm willing to build/buy piggy back boards or almost anything
else. Thanks for any suggestions.
Roy
------------------------------
Date: Fri, 7 Aug 87 08:43:48 EDT
From: "Craig F. Reese" <cfreese%super.org@relay.cs.net>
Subject: ICS-100 AD/DA board on a SUN?
I am posting this for a newsless friend: (please reply to cfreese)
Does anyone have software for or experience with the ICS-100 AD/DA
board with a SUN workstation. I believe the board is made
in Canada but sold in the U.S. by SKY computers. Any info
greatly appreciated.
Craig F. Reese
Supercomputing Research Center
USENET: cfreese@super.org
CSNET: cfreese%super.org@csnet-relay
------------------------------
Date: Thu 6 Aug 87 15:07:03 PDT
From: CONTR14@nosc-tecr.arpa
Subject: PIC tool or TeX tool?
Does anyone know if there is a public domain copy of the following tools:
a.) PIC like tool
b.) LaTex or Tex like tool
We have a network of Sun 3/50 machines and would like to use PIC with
troff instead of purchasing ditroff. LaTex or Tex may be alternatives if
the above is not possible. Please communicate directly with me at the
following address:
CONTR14@NOSC-TECR.ARPA
Thanks in advance,
Jim Baldo
[[ Editor's comments:
The VorTeX project at Berkeley distributes a package that includes a
DVI previewing tool (a DVI file is what a run of TeX produces). This is
what I use to preview TeX documents. Send a US Mail address to
"Vortex@ucbarpa.berkeley.edu" and they will (theoretically) send you a
packet of information.
I have written a tool that makes previewing PIC and Ideal figures easy.
Unfortunately, the tool runs a modified version of PIC to get the output
in an easy-to-read format. Although the tool itself is distributable, the
modified version of PIC is not.
You CANNOT use PIC with vanilla troff (unless you set up PIC to draw its
pictures with zillions of periods) because it does not have the drawing
primitives that ditroff has. --wnl ]]
------------------------------
Date: Thu, 6 Aug 87 12:58:51 PDT
From: moriarty@tc.fluke.com (Jeff Meyer)
Subject: MacPaint/PICT files --> Sun Raster/Icon formats: tools?
I have been using the utility posted a while ago, mp2sun, to transform
MacPaint files into Sun Raster files (for use in the -background option in
suntools, etc). It works fine, but there are two tasks which I have still
been unable to perform on MacPaint images, and I was wondering if any of
you more informed folks had information on tools to use:
1) Is there any tool for tranforming a *portion* of a MacPaint file into a
Sun raster file? Currently, you only get a Raster file the size of a
MacPaint file. I think I can alter mp2sun.c myself, but I was wondering
if anyone else had done it already (I'd also need something to count
pixel width and height in paint files -- andy Mac utilities to do this?).
2) Something to change portions of MacPaint images/bitmaps/icons into
Sun Icon format.
Finally, is there anything out there which transforms PICT format into Sun
Raster format (much like the "Drawing to Paint" menu item in SuperPaint).
Thanks for your time -- I'll be happy to post anything I get.
Moriarty, aka Jeff Meyer
INTERNET: moriarty@tc.fluke.COM
Manual UUCP: {uw-beaver, sun, allegra, hplsla, lbl-csam}!fluke!moriarty
<*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>
------------------------------