🚀 go-pugleaf

Yea,

me to. I can't even figure out if something similar to /dev/nit is present.

Regards,

Mats Sundvall
Dept of Medical Genetics
Uppsala, Sweden

jean@biomac.univ-lyon1.fr (Jean Thioulouse) writes:
>I have seen nothing about the compatibility between CAP 6.0
>and Solaris 2. Is it because there is no problem or because nobody
>has tried it yet ? I am particularly interested in phase 2 / enet driver
>compatibility.

This is the current status with regard to CAP 6.0 and Solaris 2 ...

IPTalk:
	"Patches allowing CAP to run in IPTalk mode under Solaris are
	coming soon". Most of these should be minor but since I haven't
	seen them yet this is just a guess.

Native EtherTalk: (Phase 1 or 2)
	As I understand it, NIT is not being supported by Solaris 2.
	Without NIT (or Stanford ENET or the Berkeley Packet Filter),
	providing Native EtherTalk support is probably impossible.

Kernel AppleTalk:
	Needs a port of netatalk or similar.

UNIX AppleTalk Bridge: (Phase 1)
UNIX AppleTalk Router: (Phase 1 or 2)
	This is likely to be the only way that Solaris will support CAP
	using direct EtherTalk delivery, at least in the short term.


We are not in a position to originate any CAP development on Solaris
since we won't be running any Solaris hosts within the forseeable future.
If you are interested in working with CAP and Solaris, please coordinate
your work through cap@munnari.OZ.AU so that duplication of effort can be
avoided.

Below is a brief list of what is required to support the various direct
EtherTalk modes of CAP. If you need more details, or samples or a pointer
to the right place in the CAP source, please ask.


Native EtherTalk: each UNIX process must be able to open a socket/packet
filter descriptor that maps to an AppleTalk socket. IE: delivery is based
on ethernet packet content. A minimum of ~32 different sockets must be
available, preferably 128 or more. The following are data "masks" to be
applied to an incoming ethernet packet, 'x' is "don't care", NN is the
destination appletalk socket, 'X' is ethernet link level address.

Phase 1: XXXXXXXXXXXX is host ethernet address or broadcast

DDP short     XXXXXXXXXXXXxxxxxxxxxxxx809bxxxx01xxxxNNxxxxxxxxxxxxxxxx
DDP long      XXXXXXXXXXXXxxxxxxxxxxxx809bxxxx02xxxxxxxxxxxxxxxxxxxxNN
AARP          XXXXXXXXXXXXxxxxxxxxxxxx80f3


Phase 2: XXXXXXXXXXXX is host ethernet address, broadcast or a number of
(up to 253) multicast addresses of the form 090007000000 - 0900070000fc

ELAP    XXXXXXXXXXXXxxxxxxxxxxxxxxxxAAAA03080007809bxxxxxxxxxxxxxxxxxxxxNN
AARP    XXXXXXXXXXXXxxxxxxxxxxxxxxxxAAAA0300000080f3
            optional or higher layer^^^^^^^^^^^^

Additionally, some form of RPC support is necessary to support the central
AARP daemon aarpd and central information server atis. Start with the file
cap60/support/ethertalk/snitp.c


Kernel AppleTalk: As an alternative to packet filters, some form of kernel
implementation of AppleTalk such as netatalk can be used to provide sockets
of type AF_APPLETALK. Start with the file cap60/lib/cap/abkas.c


UAB/UAR: a single UNIX process sends and receives all ELAP/AARP packets.
Multiple interfaces are supported and need to be opened once for each
required ethernet packet type (0x809b & 0x80f3). The file pf.c contains
samples of how to do this for SunOS, ULTRIX, IRIX, NEWS, HP-UX and AIX.
(pf.c is part of the ARNS package). Communication with CAP processes is
via the UDP/IP loopback interface.


In summary, if you rely on CAP on a SUN platform stick with SunOS. If you
are about to purchase a new workstation, vote with your feet :-)

 - David.

djh@cs.mu.OZ.AU (David Hornsby) writes:
>jean@biomac.univ-lyon1.fr (Jean Thioulouse) writes:
>>I have seen nothing about the compatibility between CAP 6.0
>>and Solaris 2. Is it because there is no problem or because nobody
>>has tried it yet ? I am particularly interested in phase 2 / enet driver
>>compatibility.

>This is the current status with regard to CAP 6.0 and Solaris 2 ...

>IPTalk:
>	"Patches allowing CAP to run in IPTalk mode under Solaris are
>	coming soon". Most of these should be minor but since I haven't
>	seen them yet this is just a guess.
As I'm porting the stuff now, most of the patches are minor. The (SUN) C
compiler is a lot more picky about types, so mostly porting means adding casts
here and there. Also the Configuration script needs work. Only one problem
left, and I'm busy with it. I'll send the patches to cap@munnari soon
(hope this week, otherwise next week).

>Native EtherTalk: (Phase 1 or 2)
>	As I understand it, NIT is not being supported by Solaris 2.
>	Without NIT (or Stanford ENET or the Berkeley Packet Filter),
>	providing Native EtherTalk support is probably impossible.
That must be investigated (I haven't looked into that yet). IPTalk support
first!


--maarten
-- 
In real life:	Maarten Carels
		Computer Science Department
		University of Amsterdam
email:		maarten@fwi.uva.nl

sundvall@perrier.embnet.se (Mats Sundvall) writes:


>Yea,

>me to. I can't even figure out if something similar to /dev/nit is present.


Oh yes, bit hidden pretty well. There's /dev/le, /dev/ie and
there's le(7), ie(7) and dlpi(7). 

They give you full access to the ethernet.

Casper