IPX and 2.1.103

[Paul Norton <pnorton@ccnvhi.com>]

What's supposed to happen:

IPX hands off the frame to p8022tr_datalink_header, which adds a three
byte 802.2 header and calls tr_header. tr_header adds a full 802.5 and
802.2 SNAP header and returns to p8022tr_datalink_header, which then
strips off the 802.2 SNAP header tr_header just put on. dev_queue_xmit
then queues the frame for transmission. 

What really happens: 

It doesn't look like the 802.2 SNAP header that tr_header lays on the
frame ever gets removed. Hence we get:

|802.5 hdr|802.2 hdr|SNAP hdr|802.2 hdr|IPX hdr|...data...|

(That's what I call a real herd of headers. :-)

What's really bizarre is that often the dsap != ssap in the first
802.2 header.  That shouldn't happen.

The last couple of weeks I've been rewriting all this code anyway. I
want to pass IP (which is SNAP), IPX SNAP and IPX 802.2 through the
correct datalink layers in the code (p8022.c, psnap.c) and get rid of
that 802.2TR one-step-forward-two-steps-back nonsense.  There's no
good reason why we should have separate 802.2 code for token-ring.
Interestingly I've got 802.2 IPX working like a champ, and I think I'm
very close with SNAP.

Gilbert Ramirez Jr. writes:
 > So, not only are there 2 LLC headers, but the non-SNAP header plus the
 > first 5 bytes of the 802.2 payload (IPX) are being copied over the 802.2
 > payload.  The bytes difference is 8 bytes.... the same size as a SNAP
 > header! Some code is assuming too much SNAP.