You are absolutely correct in your comment.
Several of us use the “simple-minded NDIS-oriented definition” of a MAC header size as being the universally-constant 14-bytes (for Ethernet) on Windows. This can be calculated by making NDIS queries for TotalSize and MaximumFrameSize and taking the diffference; I’ve never seen anything other then 14 as the HeaderSize calculated this way (for Ethernet), and I’m sure a lot of stuff would break if the first 14 bytes weren’t in one NDIS buffer.
In the case of SNAP the first-level decision can be made looking at the DataLength. If it is less than 1500 bytes then you know that DataLength is the first WORD of Netware RAW, 802.3 w/LLC Header or 802.3 w/LLC SNAP Extension that is continued after DataLength.
Regards,
Thos
----- Original Message -----
From: Ed Lau
To: NT Developers Interest List
Sent: Thursday, July 19, 2001 4:20 PM
Subject: [ntdev] RE: Ndis IM driver
I don’t think such a packet (with part of the MAC header in the lookahead buffer) can be ignored - I see them routinely on our LAN (not necessarily TCP/IP, though). What I have seen in practice is that the header buffer contains 14 bytes of the 802.3 SNAP header, and the remainder is in the lookahead buffer (I have never seen a header buffer of less than 14 bytes). The 802.3 SNAP header has the following layout:
typedef struct _E8023SNAPHDR
{
CHAR TargetAddr[ETH_LENGTH_OF_ADDRESS];
CHAR SourceAddr[ETH_LENGTH_OF_ADDRESS];
HWORD DataLength;
BYTE LLCDSAP;
BYTE LLCSSAP;
BYTE LLCCTL;
BYTE SNAPOID[3];
HWORD PacketType;
} E8023SNAPHEADER;
(an HWORD is simply a WORD - 2 bytes)
Since you can’t determine the packet type from the first 14 bytes, I don’t believe it is a safe assumption to just throw it away, even if you’re only interested in certain protocols such as TCP/IP - just my 2 cents worth -
Ed Lau
MidCore Software, Inc.
www.midcore.com
----- Original Message -----
From: Michal Vodicka
To: NT Developers Interest List
Sent: Thursday, July 19, 2001 2:28 PM
Subject: [ntdev] RE: Ndis IM driver
> From: Thomas F. Divine[SMTP:xxxxx@pcausa.com]
> Reply To: NT Developers Interest List
> Sent: Thursday, July 19, 2001 5:13 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Ndis IM driver
>
> The ordginal poster was asking specifically about the MAC header. Both
> your observations and mine are that the 14-byte MAC header in always in
> one NDIS buffer descriptor.
>
Mine too. I believe breaking MAC header between multiple buffers is really
perverted idea and such a packet can be ignored. Of course, driver should
test this possibilty and don’t crash.
>
> I have seen the rest of the MAC payload broken into multiple NDIS buffers
> as you described on send, but not on receive. MS has indicated that on
> receive at least some versions of the TCP/IP stack require everyting
> through the Lookahead data to be in one NDIS buffer. I wonder what the
> real requirement is…
>
I recall something like this. Maybe the requirement wasn’t for whole
lookahead buffer but for the first 128 bytes only. It was in some KB
article…
>
> This re-enforces guidance to never make any assumptions concerning how
> NDIS buffers might be chained in any NDIS packet that you did not create
> yourself…
>
Sure, this is the best advice. We should write a filter or protocol driver
which would use one NDIS buffer for every single byte. It should be easy to
change passhtu sample this way on send path. I wonder if any below layered
driver survives 
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
>
You are currently subscribed to ntdev as: xxxxx@midcore.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com —
You are currently subscribed to ntdev as: xxxxx@pcausa.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
