Sun-Spots-Request@RICE.EDU.UUCP (05/21/86)
SUN-SPOTS DIGEST Tuesday, 20 May 1986 Volume 4 : Issue 14
Today's Topics:
Courier on SUN
Courier, 4.3BSD, and Sun XNS
Bug in iconedit (SUN/3.0)
Subnets on Sun release 3.0 (long)
Sun User Group Tape Donations
SCSI Tape Drive Problem on a 2/120?
Memory boards for Sun-3/160s?
SUN network configuration?
------------------------------------------------------------------------
Date: Fri, 16 May 86 13:06:42 edt
From: jqj@gvax.cs.cornell.edu (J Q Johnson)
Subject: Re: Courier on SUN
In SUN-Spots Digest, v4n13, there is a request for information about Courier
on the SUN. As the implementor of the 4.3BSD XNS Courier, perhaps I can
clarify what is and isn't available.
First, there is in fact a fairly substantial Courier implementation, compatible
with the Xerox Courier, distributed as part of 4.3BSD. This is not the same
as the "Courier" distributed with 4.2BSD, which was written by Eric Cooper and
used TCP as a transport mechanism; however, some of the code for the XNS
Courier package is taken from Eric's. The package consists of a compiler for
Courier "programs" and a fairly substantial runtime library. As distributed
with 4.3 it is adequate for implementing Courier clients, but has some
problems if you want to build a Courier server. Existing example applications
include a Xerox- compatible telnet (a.k.a. GAP) client and server, a file
transfer client similar to TCP ftp but using Xerox Filing (so you can get at a
Xerox file server), a printing client (to send Interpress masters to a Xerox
print server), etc. It all requires the lower level XNS support (SPP)
provided in the 4.3BSD kernel; the Courier code is all user-mode.
I have ported the Courier compiler to the Gould and microVAX, and estimate
that porting it to a SUN would probably be only an hour or three of work.
However, SUN currently does not offer a compatible SPP implementation, so
there isn't much point. When and if SUN offers XNS/SPP support based on the
Berkeley 4.3 code, the Courier compiler will also be available.
Please send me mail directly if you have further questions or a serious
interest in implementing Courier-based applications under UNIX.
-----------------------------
Date: Fri, 16 May 86 14:32:43 EDT
From: Steve D. Miller <steve@mimsy.umd.edu>
Subject: Information on Courier, 4.3BSD, and Sun XNS
I've got a Sun kernel (based on the 2.0 release) that has all the 4.3BSD
networking stuff in it including XNS, the protocol that Courier lives on top
of. It also has NFS back in it, and can (to a greater or lesser extent; it
works, but still acts sort of strangely at times) talk NFS over either
UDP/IP or XNS (via a fragmented datagram protocol I designed one weekend).
I have not yet put ND back in (I'd prefer to do so from the official Sun
source, and they aren't giving it out as yet), put the hacks back to support
diskless Suns, or tested it all that extensively. It can and does talk
to our local Xerox machines, can apparently talk to our 4.3BSD vaxen, and
(since NFS works again) is even usable (for the most part) on a day-to-day
basis.
4.3BSD has (as user-contributed software) the Cornell Courier compiler,
which consists of a compiler that turns high-level descriptions of
Courier "programs" into a skeletal implementation and provides *lots*
of libraries that facilitate writing Courier code under 4.3BSD. It is,
in fact, easier to write Courier applications with the Courier compiler
than it is to do so in Mesa under XDE; those using Interlisp might have
an easier time doing Courier stuff on the Xerox end. I haven't tried
compiling it quite yet (though I probably will in a week or two), but
could let you know how it goes if you'd like.
I'm not certain, but I think that Courier can run across the old
Xerox network protocol suite (PUP) and I also think that a lot of
Interlisp machines talk PUP as much as possible (XNS wasn't really
supported in Interlisp until recently; I think that many Interlisp
tools try rpc calls via PUP, then try XNS if they fail). If your
application is something which you (or whoever) will be writing
both ends of then this is probably a non-problem, but if you're trying
to use a 4.3BSD machine as a Xerox file server or something then
your life may be harder.
-Steve
Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-1516
CSNet: steve@umcp-cs UUCP: {seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
-----------------------------
Date: Mon, 19 May 86 14:58:23 EDT
From: Barry Shein <bzs@BU-CS.BU.EDU>
Subject: Bug in iconedit (SUN/3.0)
Description:
Selecting text in iconedit would cause core dumps
Repeat-by:
Same
Fix:
Initialize abc_string in iconedit_canvas.c to point to a null string
rather than default to be a null pointer. Diff follows (trivial.)
-------
*** /usr.MC68020/src/sun/suntool/iconedit/iconedit_canvas.c.orig Mon May 19 14:43:41 1986
--- /usr.MC68020/src/sun/suntool/iconedit/iconedit_canvas.c Mon May 19 14:45:12 1986
***************
*** 18,24
/**************************************************************************/
CELL_POS abc_cell_origin,abc_h_cell_origin,abc_feedback_origin;
! char *abc_string;
struct pr_size abc_size;
int abc_len;
struct pixfont *abc_font;
--- 18,27 -----
/**************************************************************************/
CELL_POS abc_cell_origin,abc_h_cell_origin,abc_feedback_origin;
! /*
! * BZS@BU-CS.BU.EDU - 5/19/86: was core dumping, add init to null string
! */
! char *abc_string = "";
struct pr_size abc_size;
int abc_len;
struct pixfont *abc_font;
----
-Barry Shein, Boston University
-----------------------------
Date: Thu, 15 May 86 23:59:49 edt
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Subject: subnets on Sun release 3.0
This describes a set of patches needed to make Sun's under 3.0 handle
a network with subnets. I have tried to make these instructions as
complete as possible. However you are still going to have to know how
to use adb, and have some basic knowledge of Unix. If you do not have
a moderately experienced system hacker, I suggest consulting with your
Sun support people. In some cases addresses are given. These may
apply only to release 3.0 final for 68020's. We have also installed
these patches using these instructions on the 68010 release.
It is important to understand exactly what I mean by subnets, since
incompatibilities in this area can cause your network to become
saturated by erroneous broadcasts. Our changes are designed for a
class B network, i.e. one where addresses are of the form 128.6.s.h,
where 126.6 is our assigned network number and s and h (each 8 bits)
are under our control. We use s as a "subnet number". Each physical
Ethernet cable has its own subnet number. h is then a host on that
subnet. E.g. 128.6.4.2 is host 2 on subnet 4. Normally, Unix
considers 128.6 to be a network number, and 4.2 to be a host number.
The problem with this is if you have a machine with interfaces two
different subnets (e.g. a gateway between them). Suppose we have a
machine with addresses 128.6.4.2 and 128.6.5.3. What we want is for
any packets destined for 128.6.4 to go out 128.6.4.2, and any packets
destined for 128.6.5 to go out 128.6.5.3. However standard Unix
thinks that both of these interfaces are on network 128.6, since it
doesn't know that the next byte is part of the network number. Thus
it has no way to decide which interface to use for which packet. It
will normally send all the packets out the first interface. When we
install subnetting, we simply tell Unix that the 3rd byte is part of
the network number. Then it will realize that the two interfaces are
on different networks, and do things right. Note that we only want
the system to do this for our own subnets. There is no need for us to
see other sites subnets as separate networks. Indeed doing so could
be quite inconvenient, since it could require us to list everybody's
subnets separately in all of our routing tables. Thus the code used
for subnets checks for to see whether the address begins with 128.6.
If so, it also treats the next byte as part of the network number.
Before giving the patches, I would like to point out some effects
of doing this:
- enabling subnets means that you will need more information in
your routing tables. Without subnets, the system will
think that all of 128.6 is a single network. Thus it
will issue ARP requests when it wants to get to any
host on 128.6. With subnets turned on, it will think of
each 128.6.s as a different network. You will need
entries in the routing table to tell you how to get to
all subnets other than your own. This will have to be
done via the route command or routed.
- enabling subnets changes the definition of broadcasts.
Without subnets, a broadcast would use address 128.6.0.0.
With subnets, it uses 128.6.s.0. E.g. a broadcast on
subnet 128.6.4 would use address 128.6.4.0. All Suns
on a given Ethernet must agree as to whether subnets
are in use or not. If they do not, broadcasts will
generate errors or ICMP redirects. We are not sure
exactly what goes on, but we can tell you that booting
a diskless Sun on a network where half the machines know
about subnets will cause every Sun on the network to hang.
- when you install the patches, you must be sure to put the
patches on every machine on the network. Don't forget
copies of files sitting on diskless clients.
Now, for the patches. In theory, they are quite simple. There are
two routines used in both the kernel and the utilities to decode
addresses. That's all you need to change. The problem is that we
(and probably you) don't yet have source to 3.0, and even if we did,
it would be painful to recompile every utility on the system. Thus we
are going to give instructions for installing these patches without
source. If you have source, all you have to do is patch
/usr/include/sys/in.h and whatever copies of this may
be in kernel source directories
the routines in_netof and in_lnaof in netinet/in.c
the routines inet_netof and inet_lnaof (which should be
identical to the in_ versions) in the C library
the corresponding routines in any programs you may
rebuild that don't use the C library (e.g. boot,
which has its own copies).
Then rebuild the kernel and any relevant network utilities.
Here are the changes to in.h, and the new versions of the two
routines. (They are so short that diff's don't make a lot of sense.)
Note that our version of the patches involve hardcoding our class B
address (128.6) into the code. There are more elegant ways, but this
is the easiest. Make sure that you change the definitions to use your
class B address instead of ours. (If you are partitioning a class C
network, e.g. into a 4-bit subnet and 4-bit host, you should be able
to figure out what to change.)
*** in.h.ORIG Tue Mar 25 20:24:09 1986
--- in.h Tue Mar 25 20:17:22 1986
***************
*** 87,92
#define s_impno S_un.S_un_b.s_b4 /* imp # */
#define s_lh S_un.S_un_b.s_b3 /* logical host */
};
/*
* Definitions of bits in internet address integers.
--- 87,99 -----
#define s_impno S_un.S_un_b.s_b4 /* imp # */
#define s_lh S_un.S_un_b.s_b3 /* logical host */
};
+ /* definitions set for subnetting code: cwm 10/23/85 */
+ /* If not at Rutgers, "MYSUBNET" should be your own class B address, */
+ /* not 0x80060000, which is 128.6.0.0, i.e. Rutgers class B address */
+ #define MYSUBNET 0x80060000
+ #define SUBNETMASK 0xffff0000
+ #define SUBNETNET 0xffffff00
+ #define SUBNETSHIFT 8
+ #define SUBNETHOST 0x000000ff
+ /* end of subnet addtions cwm 10/23/85 */
============== end of in.h diff =================
The following are the new versions of in_netof and in_lnaof. We put
them in a file called "gatechanges.c", and arrange for it to be loaded
into our kernel near the beginning (before the module "in"). Then
they override the ones from in.c. (You will get an error from the
loader complaining about multiply-defined symbols, of course.) If you
have kernel source, a better approach would be to replace the routines
in in.c with these versions. Make sure you put the modified version
of in.h in the right place so that it is included below.
================= file gatechanges.c ================
#include "../h/param.h"
#include "../h/mbuf.h"
#include "../h/protosw.h"
#include "../h/socket.h"
#include "../h/socketvar.h"
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../net/if.h"
#include "../net/route.h"
#include "../net/af.h"
in_netof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
/* subnet hack, taken from topaz's subnet code cwm 10/23/85 */
if ((i & SUBNETMASK) == MYSUBNET)
return (((i)&SUBNETNET) >> SUBNETSHIFT);
/* end of subnet hack cwm 10/23/85 */
if (IN_CLASSA(i))
return (((i)&IN_CLASSA_NET) >> IN_CLASSA_NSHIFT);
else if (IN_CLASSB(i))
return (((i)&IN_CLASSB_NET) >> IN_CLASSB_NSHIFT);
else
return (((i)&IN_CLASSC_NET) >> IN_CLASSC_NSHIFT);
}
/*
* Return the host portion of an internet address.
*/
in_lnaof(in)
struct in_addr in;
{
register u_long i = ntohl(in.s_addr);
/* subnet hack, taken from topaz's subnet code cwm 10/23/85 */
if ((i & SUBNETMASK) == MYSUBNET)
return ((i)&SUBNETHOST);
/* end of subnet hack */
if (IN_CLASSA(i))
return ((i)&IN_CLASSA_HOST);
else if (IN_CLASSB(i))
return ((i)&IN_CLASSB_HOST);
else
return ((i)&IN_CLASSC_HOST);
}
================== end of gatechanges.c =====================
If you replace the routines in in.c and the C library and recompile
the kernel and network utilities, everything should be OK. The rest
of these instructions assume that you don't have source, and thus you
can't do that.
in kernel:
put gatechanges.c in the directory /usr/sys/netinet.
Arrange for this module to be compiled and linked into
your kernel near the beginning. We add the line
netinet/gatechanges.c optional INET
as the first line in /usr/sys/conf. Then you build
a kernel as described in the Sun documentation.
I have a feeling there may be something more to this,
but I can't think what.
this gets the new version of in_netof and in_lnaof into the
kernel, and causes all of the modules other than in.c
to use it. However calls to these routines from
within in.c will use the old version. Thus you will
have to adb the kernel. At in_hash+0x12,
in_netmatch+0x10, and in_netmatch+0x24, you will
find calls to the old verson of in_netof. The
actual patch is that the 16 bits at the 3 addresses
mentioned change from 7c90 to 4744, at least in our
copy. (The problem with all of these patches is
that the relevant instructions are usually relative
branches, so the addresses don't appear in any
simple way.)
If you don't want to go through all of this, there is simpler
patch. Using adb, take a vanilla kernel and do the following:
in_netof+0xe change 66xx to 602c
in_lnaof+0xe change 66xx to 6024
What this patch actually does is make all networks to be treated as if
they were class C. That will work just fine for all of your local
subnets, but if you access other sites through the Arpanet, it will
cause you to see them as having subnets too. Maybe no big deal, but
it could expand your routing tables drastically.
Now for the utilities. The problem with the utilities is that
normally they don't have symbols. Unlike the kernel, we have no way
to rebuild the utilities from .o files. Thus it is impractical to put
the full patch into them without source. We settle for the compromise
patch that cause all networks to be treated as class C. Fortunately,
the utilities involved are all involved with managing local networks.
Thus this patch is no problem. (I assume you don't boot or get yp
service over the Arpanet.)
in ypbind:
at inet_netof+0xa, change a conditional branch to
bras inet_netof+0x3c. Alas, there are no symbols in
this module, so the actual patch is at 3b42, where
we change 66xx to 602c.
in boot. There are several copies of boot. /pub/boot has symbols.
There are also copies in /tftpboot/ndboot... for Sun 3's. I'm not
sure exactly where the Sun 2 boot lives. Anyway, there seem to be two
versions of boot. /pub/boot has symbols, so the patch is easy.
/tftpboot/ndboot... doesn't have symbols, but it seems to be pretty
much the same as /pub/boot, but with all locations 0x90000 less.
at in_lnaof+0xe, change 660a to 6024. (this changes a
conditional jump to a bras to the class C code)
in the copies on /tftpboot, this is at location 0x5514
at in_broadaddr+0xe, change 66xx to 6040. (ditto)
In the copies on /tftpboot, this is at location 0x5558.
in umount, which is on all clients.
at 3f5a, change 66xx to 602c. This is the inet_netof patch.
Other utilities: We do not use routed. If you do, you must put in the
equivalent patches. Somehow you will have to find inet_netof and (if
it is used) inet_lnaof and do patches like those above. Do not run
routed (or in.routed) without patching it.
The route command should also be patched. It turns out that on our
Suns we use route only to establish a default route. (Our gateway
issues ICMP redirects to do all the rest of the routing.) Thus we
haven't bothered to patch it. "route add 0 ..." [which you use to
establish a default] works without the patch. If you use route to set
routing entries for any of your subnets, you will need the patch.
-----------------------------
Date: Thu, 15 May 86 14:14:20 pdt
From: David M. Hartwell <hartwell@lll-lcc.ARPA>
Subject: Sun User Group Tape Donations
It is time for another Sun User Group Tape. I am requesting that you
all consider the following:
"What programs have I (written/accuired) that I can put on the Sun User
Group tape?"
"What Public-Domain programs do I have on my Sun that I could give to
the Sun User Group?"
If a lightbulb turned on when you put these questions to yourself, please
take the time to contact me.
David M. Hartwell
(415) 423-4457 /* work phone */
Hartwell@lll-crg.ARPA /* ARPA address */
{ anubis dual ohlone styx unisoft }
{ arete2 hrvsmth ptsfa sun vecpyr }
{ atari ihnp4 pyramid symmetrics well }!lll-lcc!hartwell
{ caip lawliv2 qantel tflop }
{ csuh leadsv rtgvax topaz } /* USENET address */
{ delftcc lethe ssyx ucscc }
-----------------------------
Date: Thu, 15 May 86 14:25:18 -0500
From: Jeff Edelheit <edelheit@mitre.ARPA>
Subject: SCSI Tape Drive Problem on a 2/120
I have a rather annoying problem that occurs on a fairly frequent basis.
It seems that when I try to access the SCSI tape drive (do a mt, tar,
dump, restore), my 2/120 locks-up. The only fix is to reboot the
whole system.
I have been told that the problem is related to the tape drive driver.
Is this correct? Has anyone found a fix?
Jeff Edelheit (edelheit@mitre)
The MITRE Corporation, 1820 Dolley Madison Blvd.
McLean, VA 22102 (703) 883-7586
-----------------------------
Date: Wed, 14 May 86 17:28:53 EDT
From: Steve M. Burinsky <smb@mimsy.umd.edu>
Subject: memory boards for Sun-3/160s
I am looking for memory boards to upgrade my 160 for less than the $6k
that Sun wants. I saw a board by LCF (whoever they are) for $2.4k.
Any others out there? Anybody have any experience with any? I'm
mainly looking for 4Mbyte boards, but would like to hear of any others
worth mention.
Steve
-----------------------------
Date: Thu, 15 May 86 15:16:18 -0200
From: Thomas Lemke <unido!lemke@seismo.CSS.GOV>
Subject: SUN network configuration
We have the possibility to extend our family of machines in the near
future, but we don't know whether this will lead us into horrible
answering times of the system. If everything goes right, we could
get
- 1 SUN 2/130, which is extended to the size of a 3/160;
- 1 SUN 2/50;
- 4 SUN 3/50;
all these being connected via Ethernet. The SUNs x/50 shall become
diskless nodes.
The SUN 2/130 should control
- 1 SCSI-Disk (70 MegaByte) and
- 2 SMD-Disks (370 MegaByte each).
Every workstation is intended to be connected with 2 Ataris, so that there
will also be
- 12 Atari 520 ST+ (or something like that).
All together, there would be 18 (!) working places accessing one SUN
2/130 (resp. 3/160).
Before doing all this, we would really like to know whether efficient
work will be possible on this configuration. Thanks for every hint
concerning this.
========================================================================
Thomas Lemke
c/o Universitaet Dortmund
Abteilung Informatik
Lehrstuhl VI
Postfach 500 500
46OO Dortmund 50
Federal Republic of Germany
==============================
UUCP: ...!mcvax!unido!lemke
...!mcvax!unido!luise!tl
...!seismo!unido!lemke
==============================
-----------------------------
Date: Fri, 16 May 86 09:44:08 PDT
From: Leah Y. Wong <wong%cod@nosc.ARPA>
Subject: SUN - IDM 500
As I understand, currently there are host software available for the
VAX/UNIX, VAX/VMS, and PC hosts to interface with the Britton Lee's
IDM 500 Database machine.
I would like to know if any SUN/UNIX users have developed host
software which will interface with the IDM 500 via ethernet(TCP/IP)
or IEEE488.
Your suggestions or comments will be greatly appreciated.
Please mail your response directly to me. I plan to submit a
followup article.
Leah Y. Wong
Code 443
Naval Ocean Systems Center
MILNET/ARPANET: wong@nosc
UUCP: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!noscvax!wong
-----------------------------
End of SUN-Spots Digest
***********************