Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!husc6!spdcc!ftp!dab From: dab@ftp.COM (Dave Bridgham) Newsgroups: comp.dcom.lans Subject: Re: NOVELL networks Summary: Explanation of the different Novell encapsulations Message-ID: <670@ftp.COM> Date: 8 Jun 89 15:38:24 GMT References: <11806@s.ms.uky.edu> <161@uvacs.cs.Virginia.EDU> <9585@j.cc.purdue.edu> Reply-To: dab@ftp.UUCP (Dave Bridgham) Distribution: usa Organization: FTP Software, Inc. Lines: 26 The headers on Novell packets are a whole lot like XNS headers. The difference is that they don't allocate their well known sockets (or whatever XNS calls them) from Xerox but just allocate their own from numbers greater than 0x8000 and they don't use the packet type for XNS. As a matter of fact, by default they don't use any packet type at all. They take the IEEE 802.3 path of putting a length in the type field. Because they don't then go on to use the 802.2 header to put a type field back in, the default Novell packet format won't co-exist with other 802.2 packets on an ethernet. For those people who need this Novell added the ability to configure their software (using the ECONFIG command) to use the type field as it was originally intended (using ether type 8137). This change is also needed to make Novell work with something like the Packet Driver (which demuxes packets by the type field). Since Novell can use a packet type, it then also has a third possible encapsulation for use on those networks which really want only 802 packets running about. In this scheme, the type field is a length, it's followed then by a 3 bytes SAP header and a 5 byte SNAP header (see RFC1042 for the details). The SNAP header contains the 2 byte ether type and everything looks like ethernet from there out (except the MTU has shrunk a little). I havn't heard of anyone using this scheme yet. David Bridgham FTP Software, Inc.