Newsgroups: comp.sys.3b1
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!sci.ccny.cuny.edu!jeffrey
From: jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger)
Subject: Re: Etherneting a 3B1 and Sun 3/60 (it works)
Message-ID: <1991May24.161142.723@sci.ccny.cuny.edu>
Followup-To: comp.sys.3b1
Summary: yes, but...
Keywords: 3B1 Sun 3/60 Ethernet
Organization: City College of New York - Science Computing Facility
References: <2869@public.BTR.COM>
Date: Fri, 24 May 91 16:11:42 GMT

In article <2869@public.BTR.COM> thad@btr.btr.com writes:
>The network number of the net on which the Sun 3/60 was located differed from
>the network number I use in my lab, so I first tried the "obvious" things with
>/etc/gateways, mucking up the /etc/hosts, editing /etc/networks, etc etc to
>no avail.  In all cases, "Host is not reachable."

While I may not be much of a guru on this stuff, it might be a routing
problem.  Namely, the Sun did not know that the route to this IP
network was thru the main interface.  If you aren't running the routed
(or somesuch other thing), you'll have to manually add the route.

>So a brute force technique was next tried: I changed the Internet number of
>my 3B1 in /etc/hosts to be on the same net as the Sun and altered the file
>/etc/lddrv/ether.rc to set the 3B1's "new" hostid on the same net as the Sun,
>rebooted, and voila!  All works just perfectly, even rwhod, etc.   rlogins

You chose the easiest thing, especially if you didn't "correctly aquire" a
class C net for your lab.  Who knows, someone else might legally have
claims to the number you chose for your local net!  Now *that* would
make routing problems.

>What's even funnier is that that IBM PC/AT was running WIN/TCP 4.something
>and the 3B1 is using the old WIN/3B version 1.something.  Hmmm, a multi-tasking
>10MHz 68010 outperforming (again) a single-tasking 12MHz 80286; MS-DOS vadanya!

The latest version (1.4) is still rather trashy.  If I wasn't so
addicted to ethernet, I'd burn the disks.  And as for the 286 being
slow, I'd hesitate to say it was MessyDos slowing you down.  It was
probably their port of the software.  And 286 chips *are* useful!  I
glue little google-eyes on them and sell them as bugs!  :-)

>I do NOT understand why I couldn't
>have hosts whose IP numbers were, say, 192.9.200.* talk to hosts whose IP
>numbers were, say, 128.15.22.*, all connected on the same ThinNet backbone;
>maybe now's the time to RTFM!  :-)

My first guess is a packet routing problem.  It's easier to set up the
3b1 than to redo the Sun.  From what I can see, both networks are
reachable, but doing a quickie reroute can be more of a headache than
resetting your IP number.

>As far as TCP/IP on the 3B1 goes, everything generally seems to operate as
>one would expect.

Operates as per a *bad* 4.2 port.  I mean, these folk decided to spawn
off each daemon separately.  Now the inetd (inet superdaemon) is more
the norm.  One process instead of 30.  And wait 'till you try to use
AF_UNIX sockets...

>along with some 4.3BSD ports I did last year.

Andy Poling also has some stuff ported.  I was trying to clean some
stuff up (and sent the patches back to him) but some of the BSD code
just won't work on sys 5.  You might ask when he'll be finished with
them.

>Some of this stuff DOES work with the 3B1's shared libraries (4.3BSD's ftp, for
>example), and some does NOT work with the 3B1's shared libraries (the "whois"
>stuff, for example).  Dunno why.

The main reason is that there are a lot of things that are redefined in
libnet.a  Things like perror.  The system's default is to use the
shlib copy and ignore the library's version.  After finding no help to
selectively include/exclude routines, I just gave up on the shared
libs.  Also, there are *significant differences* between gcc (1.37.1)
and the stock cc.  Some things (like sendmail) trash out the cc, but
need fancy options for gcc.  I still haven't gotten the BIND stuff to
work correctly. :-(  And quite possibly, a new BSD ftpd cannot ever
work, due to the setuid/geteuid stuff.

>Summary: a 3B1 and Sun 3/60 (with SunOS 4.1.1) do internetwork just fine.

The concept of "standard TCP/IP" is nice, but.  If TWG had had a
bigger base of ethernet users, and had tried an update, things might
work better.  For example, have you noticed that when you login thru
the network, it tells you the last time you logged in.  Nice touch,
like Lenny's program.  Except that the only time it is updated is when
you log in thru the net!  The file /usr/adm/lastlog is not referenced
in /bin/login, only in netlogin.  Talk about hacks...

Anyways, I was interested (past tense) in remaking the driver.  If you
want, I can give you a copy of the notes/plans I had.  My thesis kinda
got in the way.  I'm a biologist, not a Comp Sci person :-)  Maybe a
collective *we* can give it another try.  Start with the uipc driver,
and add the rest.

j
-- 
Jeffrey L. Bromberger
System Operator---City College of New York---Science Computing Facility
jeffrey@sci.ccny.cuny.edu			jeffrey@ccnysci.BITNET
	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey