From: harvey@indyvax.iupui.edu
Newsgroups: comp.sys.novell
Subject: Re: BYU packet driver IPX doesn't do SPX
Date: 28 Jul 92 01:56:41 GMT
Organization: Indiana University

I just hate to interrupt this thread, but I had some thoughts on the original
question which started it all, which was (see subject line :-)...

...that certain applications that used SPX would not work when using
either (1) the BYU IPX driver or (2) the more recent Intel IPX driver.

Now, SPX just uses IPX (right?), so it would seem odd that a working IPX
driver would not work with a particular application that uses SPX...

    ...unless...

        (1) IPX is being encapsulated using Novell's "raw 802.3" format
    and
        (2) the application enables IPX checksumming

In this case it is quite clear why the application breaks.  Packet drivers,
when used to get/put Novell's "raw 802.3" format on the wire, depend on the
IPX header's checksum field being all 1s in order to recognize IPX packets
as IPX.  This is the case for:

o   The BYU IPX driver used with a class 1 packet driver using the -n option.

o   The Intel IPX driver, not ECONFIGed, used with a class 11 packet driver.

o   The Intel IPX driver, ECONFIGed, used with a class 1 packet driver using
    the -n option.

In each case what is really appears on the wire is "raw 802.3" IPX.  All 1s
means IPX checksumming is disabled.  If checksumming is enabled, there is no
way to distinguish "raw 802.3" IPX packets from any other, and the application
stops receiving packets.  The cure is to switch to an encapsulation that does
not have this problem (e.g., Ethernet II, or 802.3 w/802.2 or SNAP headers).

It would be interesting to find out what encapsulation is being used at sites
seeing the SPX problem.  The presence or absence of IPX checksumming could be
confirmed by looking at the packets with a network monitor (of course, you
would have to look at a lot of them and figure out what they "really are"
yourself, since the network monitor has no way to distinguish IPX either
in this case! :-)

Some things to keep in mind about Novell's "raw 802.3" encapsulation:

o   The "raw 802.3" encapsulation was not designed to co-exist with other
    protocols on the wire.  Novell doesn't recommend this either (right?)
    However, many people get away with it because...

o   ...Many packet de-multiplexing drivers are hacked to support "raw 802.3"
    encapsulation, but require IPX checksumming to be disabled in order for
    this to work.  This includes the implementation of the -n option with a
    class 1 packet driver, and registering for a pattern of 0xFFFF with a
    class 11 packet driver.

o   Historically, IPX checksumming is usually disabled.

o   Applications can enable it though.  These break when used with the
    hacked drivers (and "raw 802.3" encapsulation on the wire).

o   The "raw 802.3" encapsulation is incompatible with the IEEE 802.2 LLC
    standard.  Because of this, there is no (reasonable) way to tell certain
    controllers to send and receive it (e.g., VAX Ethernet/802 controllers)
    and the mere presence of "raw 802.3" packets can drive some controllers
    bonkers (reportedly certain Un*x workstations?).

The "raw 802.3" encapsulation will probably be around forever, since it has
historically been the default encapsulation for IPX.  If you must use it,
however, you should be aware of it's limitations...

--
James Harvey    IUPUI OIT Technical Support/Networks
harvey@iupui.edu  uucp: iugate!harvey  bitnet: harvey@indyvax
Newsgroups: comp.sys.novell