Developer Forum

I have observed that TCPIP on Windows platforms will accept a 802.2
SNAP encoded packet as an "IP" packet if the "Local Code" field of the
SNAP header specifies the IP EtherType (0800). It does so even when
the "OUI" field is non-zero and therefore not in convormance to
RFC1042.

Can anyone comment on whether this is 'by design' to address some
interoperatiblity issue or simply an incomplete conformance to the
standards?

Thanks.
-dave

In article < XXXX@XXXXX.COM >, XXXX@XXXXX.COM (David R. Cattley) writes:
| I have observed that TCPIP on Windows platforms will accept a 802.2
| SNAP encoded packet as an "IP" packet if the "Local Code" field of the
| SNAP header specifies the IP EtherType (0800). It does so even when
| the "OUI" field is non-zero and therefore not in convormance to
| RFC1042.
|
| Can anyone comment on whether this is 'by design' to address some
| interoperatiblity issue or simply an incomplete conformance to the
| standards?

I have no idea if it is by design (I'd guess they just neglected to check)
but I'll bet it makes some things work that would otherwise not, e.g., when
a mis-matched WLAN setup lets 802.1H-encapsulated Ethernet packets through.

Dan Lanciani
ddl@danlan.*com