> In doing some 802.11 captures, I am seeing some LLC frames that look
> like they should be IPX. The LLC header begins with FF FF, which is
> invalid for an LLC SSAP/DSAP.
The 802.11 dissector doesn't check for 0xFFFF; that's only done in the
Ethernet dissector. None of the *other* dissectors for link layers that
use 802.2 (FDDI, Token Ring) check for 0xFFFF, either.
Does Netware put raw link-layer packets, with no 802.2 header, on any
link layer *other* than 802.3?
(This might be a consequence of 802.11 being treated as "wireless
Ethernet", even though it's not - it appears to be an IEEE link layer,
with the usual expectation of an LLC header, even if 802.11 drivers
present the illusion of an Ethernet driver to the rest of the networking
stack, as I think they might. That particular form of illusion might
not be presented by FDDI and Token Ring drivers.)
> Interestingly, Ethereal proclaims that the hex 0xff is
> really 0xfe,
No, it proclaims that a DSAP byte of 0xFF is a DSAP of 0xFE and an
Individual/Group bit of 0x01, and that an SSAP byte of 0xFF is an SSAP
of 0xFE and a Command/Response bit of 0x01, as would be the case for any
other DSAP or SSAP bytes (i.e., they're 7 bits of SAP and one flag bit).
> Captures on request so as not to email the entire list with it.
Send the capture to "guy@xxxxxxxxxxxx"; I'll look at it at some point,
and see whether they really *do* look like IPX packets.
