jbvb@VAX.FTP.COM (James Van Bokkelen) (10/06/88)
For the standard Novell not-quite-802.2 headers, would it be reasonable
to use a Packet Driver that implemented IEE 802.2 headers on Ethernet as
a separate "class" from Dec-Intel-Xerox Ethernet? If so, I would assume
you could call access_type() with:
char Novell_ssapdsap[] = {0x11, 0x11};
if_class = 11; /* Ether w/802.2 headers */
type = (char far *) Novell_ssapdsap;
typelen = 2; /* Should identify Novell */
access_type(if_class, 0xFF, 0, type, typelen, novell_receiver);
I assume normal 802.2 usage would usually use typelen = 3 or typelen = 4.
On a related topic, I am working on v1.07 of the packet driver spec, which
will incorporate some of Phil Karn's suggestions regarding not requiring
a handle on driver_info(), and allowing a type of NULL to indicate that
a LAN monitoring program will want all packets (note that this has some
inefficiencies for Netwatch-style monitoring software). I will post when
I have it available.
James VanBokkelen
FTP Software Inc.tom@rsp.UUCP (Thomas Ruf) (10/12/88)
In article <8810061458.AA11891@vax.ftp.com>, jbvb@VAX.FTP.COM (James Van Bokkelen) writes: > For the standard Novell not-quite-802.2 headers, would it be reasonable > to use a Packet Driver that implemented IEE 802.2 headers on Ethernet as > a separate "class" from Dec-Intel-Xerox Ethernet? If so, I would assume > you could call access_type() with: > > char Novell_ssapdsap[] = {0x11, 0x11}; > > if_class = 11; /* Ether w/802.2 headers */ > type = (char far *) Novell_ssapdsap; > typelen = 2; /* Should identify Novell */ > access_type(if_class, 0xFF, 0, type, typelen, novell_receiver); > > I assume normal 802.2 usage would usually use typelen = 3 or typelen = 4. That's what I've found while writing various Novell drivers : Novell uses 2 different encapsulation methods on ethernet : 1) What Novell calls "IEEE" : +dest|source|length|ipx-stuff+ i.e., just use the 802.3-like length field WITHOUT any additional link layer. Novell also insists that the length field has to be even. Most Novell ethernet drivers (3Com, Novell Ethernet) use this format as default. 2.) Ethernet style : NetWare 2.1 added a "new" encapsulation method, the one we've all been waiting for : standard ethernet type codes. Novell was assigned typecode 0x8137. I assume they were forced to go this way with the introduction of NetWare/VMS. NetWare 2.1 comes with a utility called 'ECONFIG'. It allows you to configure your driver to user either 1), or 2), OR 2) with any typecode you want. (not all drivers are configurable. The ones that are that i'm aware of : 3Com, Novell RX, Schneider & Koch) Thomas ------------------------------------------------------------------- Thomas Ruf {uunet,mcvax}!unido!rsp!tom Schneider & Koch GmbH West-Germany
jbvb@ftp.COM (James Van Bokkelen) (10/16/88)
In article <293@rsp.UUCP>, tom@rsp.UUCP (Thomas Ruf) writes:
# ...
# 1) What Novell calls "IEEE" :
#
# +dest|source|length|ipx-stuff+
#
# i.e., just use the 802.3-like length field WITHOUT any additional
# link layer. Novell also insists that the length field has to be even.
# Most Novell ethernet drivers (3Com, Novell Ethernet) use this format
# as default.
# 2.) Ethernet style :
# NetWare 2.1 added a "new" encapsulation method, the one we've all
# been waiting for : standard ethernet type codes. Novell was assigned
# typecode 0x8137. I assume they were forced to go this way with the
# introduction of NetWare/VMS.
# ...
# Thomas
Another person I heard from via direct mail also suspected that DEC's XE
driver forced them to use a standard encapsulation...
Two points: 1) I have heard references to a Novell Ethernet encapsulation
referred to as "ISO-compatible", and 2) I have seen many dumps of Novell
Ethernet packets with the following headers:
dest|source|length|0x11 0x11| 0xFF 0xFF
The FF FF and the data that follows can be understood pretty well if you treat
it as an XNS packet with no end-to-end checksum. Does "ISO-compatible" refer
to this kind of headers, and does it constitute yet a third Novell
encapsulation?
James VanBokkelen
FTP Software Inc.