ftp.nice.ch/pub/next/unix/network/system/venet.1-1.1.README

This is the README for venet.1-1.1.s.tar.gz [Download] [Browse] [Up]

README and FAQ list (March 1993)
Copyright 1993 by Eric P. Scott.  All Rights Reserved.


VENET1 is a Loadable Kernel Server for NeXT Software Release 2.x
and 3.0 that provides access to EtherTalk Phase I (AppleTalk over
Ethernet) datagrams.  It allows user-mode software to implement
AppleTalk protocols, bridges, etc. on NeXT computers.

As an example, I provide an interface to the ARNS "Remote Network
Server" package, which enables distant Macintoshes to access
local AppleTalk networks via the Internet or over asynchronous
serial line connections.

This software is not in the public domain, but may be freely
redistributed and used pursuant to the licensing terms in the
venet1.c file, which are essentially those of BSD's "NET2"
software (although VENET1 contains no code taken from NET2).


Building VENET1:

The supplied Makefile compiles the LKS and formats the manual
page.

There are two compile-time options you can enable by editing the
Makefile: FASTER_QUEUE suppresses the usual prepending of
interface information on the read queue.  This is made an option
because it violates 4.3BSD conventions.  SEGREGATE enables
additional functionality as described on the man page.

Then  make NeXT2.x  or  make NeXT3.0  as appropriate.
Build on the same major release you intend to run under and do
not attempt to load a 2.x server on a 3.0 machine--there are
significant (incompatible) internal differences.

You will need to create at least one character special file
-> on each machine that will run the LKS <-  by doing a

	make /dev/etI0

as root.  Use  make devices  if you've chosen the SEGREGATE
option (it does no harm if you didn't, but the additional devices
won't be usable).

Loading VENET1:

kl_util -a /usr/local/lib/kern_loader/venet1_reloc

(This can be done from /etc/rc.local; note that only root can
load kernel servers)


Author's address:

Eric P. Scott
School of Science
San Francisco State University
1600 Holloway Avenue
San Francisco, CA  94132
USA

e-mail: <eps@cs.sfsu.edu>
FAX:    +1 415 338 6136


Building ARNS:

You must obtain a copy of ARNS patchlevel 5 (March 10, 1993).
The package is available for anonymous FTP from munnari.OZ.AU
as mac/arns.tar.Z (165351 bytes).

mkdir arns  and  cd arns  before unpacking the archive.

	zcat ../arns.tar | tar xvopBf -

Use Larry Wall's patch utility (available from countless
anonymous FTP sites) to add support for the VENET1PF option:

	patch -p <../arns.patch

Note that this will change CFLAGS in the Makefiles to -O -bsd,
so you won't have to do this manually.  make.

(Changes made by this patch may be incorporated in future ARNS
releases.)


Running ARNS:

Specify the device name with  -i etI0; everything else is as
described on the arns man page.


The ARNS package is copyright 1993, The University of Melbourne.

-------
Frequently Asked Questions (and Answers)


Q. How did you manage to do this?  I've wanted something like it
   for years!

A. I read Writing Loadable Kernel Servers and the two books it
   suggested (The Design and Implementation of the 4.3BSD UNIX
   Operating System, and Writing a UNIX Device Driver).  Then I
   went to the SunOS 4.x documentation and read Socket-Based IPC
   Implementation Notes in the Network Programming Guide, and
   Writing Device Drivers in the Writing Device Drivers/STREAMS
   Programming volume.  Despite NeXT's "us vs. them" marketing
   campaign, NeXT always has been and remains a Sun licensee.  If
   you're familiar with SunOS 4.x internals, you're well prepared
   for what NeXT throws at you.  Also, I had access to BSD NET1
   and NET2 sources (NeXT's kernel APIs mostly agree with NET1).


Q. How much kernel hacking experience did you have before writing
   this?

A. Practically none on UNIX systems.  But I've worked on others,
   and developed a healthy respect for the perils of kernel code.


Q. How many machines did you crash before you got it right?

A. None.  In fact, it worked the first time it loaded and passed
   every subsequent test I performed.


Q. Is it really that easy?

A. Not for most people.  But I'm not most people.  I was also
   VERY careful when writing it.


Q. How long did it take?

A. Hard to say.  I worked on it in bits and pieces over a three
   week period, mostly weekends and nights.  It was definitely a
   low priority project.


Q. What was the hardest part?

A. Writing the documentation.


Q. Could you have done this without access to a 2.x system?

A. Probably not.  NeXT removed so much from the supplied header
   files in 3.0 that newcomers are left at a severe disadvantage.


Q. What about NeXT training?

A. (1) NeXT doesn't teach this sort of thing.  (2) I never
   attended Developer Camp or any other NeXTedge course.


Q. How much help did you get from NeXT?

A. None whatsoever.  In fact, they tried very hard to discourage
   me from even attempting this.  They said they're only
   interested in helping their Strategic Partners.  If they don't
   think you're working on something that's going to generate
   a lot of additional sales for them, you're just not worth
   their time.


Q. Did you obtain a major device number from NeXT Technical
   Support?

A. No.  See previous Q/A.


Q. Which major device numbers are available for user-written
   character device drivers?

A. 19-31, 37.


Q. What about the long-promised DriverKit?

A. I've never seen it, so I can't comment.


Q. Why do I get what looks like an error message when compiling
   venet1.c on a 3.0 system--something about including the wrong
   file?

A. NeXT screwed up one of their header files.  Don't sweat it.
   Don't worry about the sccsid warning either.  It's harmless.


Q. OK, the "big" question: Can I use this driver to build a
   "Native EtherTalk" version of CAP?

A. Probably not.  CAP with Native EtherTalk requires that the
   network interface be able to be opened multiple times, once
   per open AppleTalk socket, one or more per CAP process.  This
   driver currently only supports multiple opens for different
   protocols when -DSEGREGATE is defined.


Q. Does this driver see its own broadcasts?

A. Yes.


Q. Can this code be fitted with a programmable packet filter,
   a la ENET or BPF?

A. I think you'd be better off porting one of those in its
   entirety.  ENET probably involves less effort, and is probably
   more immediately useful.


Q. Can I use this as a basis for a RARP server?

A. Yes.


Q. What about EtherTalk Phase II?

A. No way.  This version does not support multicast datagrams.


Q. Can I run this at the same time as NeXT's AppleTalk
   (under 3.0)?

A. No.  You can't have two competing protocol implementations
   running on the same machine.


Q. Where can I find Apple's EtherTalk Phase I extension?

A. As far as I know, Apple last distributed it with EtherTalk
   Installer 2.0.1, in the "Previous Version" folder.  That's
   going to be difficult to find these days unless you have
   access to some old Developer CD-ROMs.  However, several third-
   parties (3Com, Asante', Farallon, to name a few) who make 100%
   register-compatible products probably have it on their
   installer disks.  You may need to perform a "Custom"
   installation to get at it.  Note that 3Com's EtherLink/NB card
   is identical to the Apple product, and its [System 6]
   installer is available by anonymous FTP from ftp.3com.com as
   adapters/drivers/3c543.sit (use StuffIt Expander to extract).
   It's also available on Compu$erve (GO THREECOM) for the FTP-
   deprived, or from 3Com's Network Adapter BBS +1 408 980 8204.


Q. I thought EtherTalk Phase I didn't work under System 7?

A. You thought wrong.  EtherTalk Phase I is compatible with
   7.0, 7.0.1, and 7.1.  Note that Apple's Network Software
   Installer will remove it; just copy it to your Extensions
   folder after running Network Software Installer and restart.
   Then select it from the Network Control Panel.


Q. Is EtherTalk 1.2 compatible with AppleTalk 58?

A. It seems to be.  The major change with AppleTalk 58 (Network
   Software Installer 1.3) is support for their SNMP agent.  If
   you're really worried about this, use Network Software
   Installer 1.2.3, or what's standard with System 7.1.


Q. Are there any security-related issues I should be aware of?

A. The Makefile creates devices with 666 permissions (read/write
   by anyone).  You may restrict access to a particular user or
   group if desired.  Asynchronous (SIGIO) notifications can be
   directed to processes which would be off-limits to kill(2).
   This problem is not unique to VENET1; programs that catch
   SIGIO should always be prepared to dismiss spurious signals.


Q. What are your future plans for this software?

A. I haven't any.  I don't promise any enhancements, support, or
   additional sample code.  What you see is what you get.
   (But I also don't promise not to pursue further development.)

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.