[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPX and 2.1.103
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.