 | 1 | initial version |
The "802.3 raw" format is not part of any version of IEEE 802.3. It was a hack by Novell; to quote Don Provan's explanation of the different Ethernet encapsulations for NetWare packets:
Ethernet_802.3 came from Novell. At some point in the development of 802.3, someone at Novell got a copy of the 802.3 specification. I wasn't around at the time, so I don't know for sure what happened, but apparently it didn't occur to anyone that a legitimate datalink protocol would simply have to carry a network layer protocol identification. (Without a protocol ID, the datalink protocol could only be used for a single protocol, which isn't very practical.)
Anyway, to make a long story short, some Novell engineer implemented 802.3, but without the required 802.2 header. (Novell apologists claim that at some point in the early days of 802.3, the 802.2 header wasn't required. I'll believe that the requirement for 802.2 might not have been clearly spelled out at some point, but I cannot believe that anyone on the 802.3 committee thought 802.3 didn't need a protocol descriminator, so I'm sure the intention was always for 802.2 to be required.) Instead of an 802.2 header, in the Ethernet_802.3 frame IPX simply sits right in the 802.3 packet as the only possible protocol.
Now normally you might think that having two protocols, IPX and 802.2, both riding in the same place in the same type of frames would cause a problem. Indeed, there have been isolated cases over the years of nodes expecting 802.2 being confused by arriving IPX packets and vice versa. But by a remarkable stroke of serendipity, IPX packets, which until just recently always started with two bytes of all ones, look ridiculous to properly implemented 802.2 code. (And, on the other hand, 802.2 packets never start with two bytes of all ones, which makes them invalid as IPX packets transmitted in Ethernet_802.3 frames.) This has made the number of problems quite limited, and such bugs in the packet handling code were generally fixed posthaste.
So whoever's sending those frames is doing something they really really really really really really really really really really really really shouldn't be doing. As Don notes, there's nothing in that format to indicate what the payload's protocol is. In this case, it looks as if it might be IPv4, given the 0x45 as the first octet.
Wireshark has no mechanisms to support that. It does attempt to handle Novell protocols running atop "raw 802.3", but, to quote a comment in the code:
Ethernet802.3: A raw 802.3 packet. IPX/SPX can be the only payload. There's no 802.2 hdr in this.
Note "IPX/SPX can be the only payload"; for packets where the type/length field has a length value, it specifically checks for the first two octets of the payload being 0xffff, and treats that as IPX/SPX.
I'd suggest manually dissecting that payload as if it were an IP header, and maybe the IP address will indicate which machine is misbehaving.
