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.