Re: NDIS miniport driver - expected frame format

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks, Peter. I appreciate your patience.

I did not realize that an EtherType was defined for 802.1Q. Found a listing
at http://en.wikipedia.org/wiki/EtherType :) It makes sense now.

We are planning on using either 802.1Q or DSCP for classification.

Thanks, again.

"Peter" wrote:

If the miniport looks at what it thinks is the type/len field (the 2 bytes
after the source address) but say the IM driver has already inserted the 4
byte 802.1Q tag between the source address and the type/len, then it will
break the logic. Right? Which is why I was wondering if this 802.1Q info
is
always send OOB in NDIS_PACKET or NBL.

If you look at bytes 12..13 from offset 0 of the packet and see that it's
0x8100 (the EtherType value for 802.1Q tag), then advance 4 bytes and then
do the type/length field determination for Ethernet encapsulation. And, as I
said, there is always a chance that an IM driver above the miniport would
insert the tag, and then you should not see anything in the OOB area. Refer
to the sample MUX driver to see what I mean.

However this will still not work on the receive side because the tag may
or
may not be present between the source address and type/len field and
miniport
driver has no way to know.

Once again, look at bytes 12..13. If they are equal to 0x8100, then advance
4 bytes to do the encapsulation check. Since 0x8100 is greater than the max
jumbo frame size, you can be assured that this value represents an EtherType
and not a length value. And, both the send/receive processing requirements
would be similar.

One thing I wonder is why you are just relying on DSCP within the TOS field
of the IP header and not the 802.1p value in the tag (if present)? Or, are
you considering on doing this?

"Peter" wrote:

Is this the reason why NDIS passes 802.1Q info in out-of-band struct?
This will work on send side but what about receive side (from wire)?

If the type/length field is 0x8100 (which is an EtherType), then you
simply
go past it to make the Ethernet II/SNAP determination. I would think
you'd
want to make this check on both the send and receive side since you do
not
know if an IM driver bound to your driver has already made the tag
insertion. On the send side, if the IM driver has made the insertion,
then
there shouldn't be anything in the OOB area for the NDIS_PACKET or (for
NDIS
6.0) the NET_BUFFER_LIST.

Depending upon where you are in the stack
"Gammaraman" <Gammaraman@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5AAF0ECD-ED93-48DD-852D-0FD9658E59D4@xxxxxxxxxxxxxxxx
Thanks again. I appreciate your help.

It looks like 802.1Q can mess up Ethernet-II interpretation because now
the
type field may be neither an ethertype nor a length.

From http://en.wikipedia.org/wiki/IEEE_802.1Q

802.1Q does not actually encapsulate the original frame. Instead, for
Ethernet frames using Ethernet II framing, it adds 4 bytes *between*
the
Source MAC Address and the Type/Length field of the original frame.
Since
the
FCS becomes invalid, it is regenerated.

Is this the reason why NDIS passes 802.1Q info in out-of-band struct?
This
will work on send side but what about receive side (from wire)?

Thanks.

"Peter" wrote:


The context behind this question is that I want to inspect the DSCP
field
in
the IP header of an outgoing NDIS packet and I need to know how many
bytes
of
layer2 header to skip to get to the IP header. Is it 6+6+2 (with
Ethernet-II
framing) or 6+6+2+3+5 (with 802.3+LLC+SNAP)? Can a NDIS miniport
driver
make
any assumptions about the framing used by NDIS?

If all you want to do is inspect the IP TOS field, then you'll need to
determine that the packet is an IPV4 packet. Again, the best way to do
this
is to look at the type/length field of the MAC header. If it is >
1500,
then
it's an Ethernet II frame and you can determine the prototol type from
the
value of this field . Otherwise, it's an 802.2/SNAP frame. TCP/IP on
Windows
only supports Ethernet II or 802.2/SNAP frames.

Keep in mind that if you are writing an IM driver (or if this a driver
for a
GB NIC), then you'll need to support jumbo frames, where packets
lengths
could be up to 9000 bytes which is larger than the protocol type for
IP
(0x0800). So, in this case, you may want to also inspect the 3 bytes
following the MAC header's type/length field. If (length > 1500) &&
(next
3
bytes != 0xAAAA03), then this is an Ethernet II frame.

Can a NDIS miniport driver make
any assumptions about the framing used by NDIS?
No. The miniport driver (and miniport edge of an IM driver) should be
agnostic to the L2 framing.

"Gammaraman" <Gammaraman@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:127016D5-E749-492F-8FB1-0BD898349EA6@xxxxxxxxxxxxxxxx
Thank you.

I apologize for being vague with my question. Here is a re-phrased
version.

On the send side, does NDIS (say 5.1) support any layer 3 protocol
which
does not have an Ethertype defined? If NDIS only supports layer 3
protocols
which have defined Ethertype values, then there is no need for a LLC
and
SNAP
header and Ethernet-II framing can be used instead.

The context behind this question is that I want to inspect the DSCP
field
in
the IP header of an outgoing NDIS packet and I need to know how many
bytes
of
layer2 header to skip to get to the IP header. Is it 6+6+2 (with
Ethernet-II
framing) or 6+6+2+3+5 (with 802.3+LLC+SNAP)? Can a NDIS miniport
driver
make
any assumptions about the framing used by NDIS?

Thanks.



"Pavel A." wrote:

"Gammaraman" <Gammaraman@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:9441A736-0520-4748-A2F6-E6C94CACBACB@xxxxxxxxxxxxxxxx
In NDIS 5.1, what kind of layer 2 headers can a miniport driver
expect
in
a
NDIS_PACKET passed down by NDIS. Is this header a Ethernet-II MAC
header
or a
802.3 header? What about LLC and SNAP headers?

I think if the Ether/len field exceeds 1500, then its a
Ethernet-II
MAC
header else its a 802.3 header. But I am not seeing the big
picture.
Can
someone please help?

Ok, here is the big picture:
The miniport will give you the real length of received packets.
You don't have to rely on the type/size fileld or SNAP header to
guess
the
length.
However, if the real length is not consistent with the packet
data,
you
(protocol or IM) decide what to do.

Regards,
--PA












.

Relevant Pages

  • Re: NDIS + EAPOL
    ... No. Native WiFi platforms based on NDIS 6.x will always transform the 802.3 ... header to ther appropriate 802.11 header, ... NDIS on such systems will give the driver and expect from the driver ... EAPOL or not (but once the group keying material is installed by ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS miniport driver - expected frame format
    ... Ethernet frames using Ethernet II framing, it adds 4 bytes *between* the ... Source MAC Address and the Type/Length field of the original frame. ... Is this the reason why NDIS passes 802.1Q info in out-of-band struct? ... layer2 header to skip to get to the IP header. ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS miniport driver - expected frame format
    ... Ethernet frames using Ethernet II framing, it adds 4 bytes *between* the ... Source MAC Address and the Type/Length field of the original frame. ... Is this the reason why NDIS passes 802.1Q info in out-of-band struct? ... layer2 header to skip to get to the IP header. ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS miniport driver - expected frame format
    ... after the source address) but say the IM driver has already inserted the 4 ... do the type/length field determination for Ethernet encapsulation. ... of the IP header and not the 802.1p value in the tag? ... Is this the reason why NDIS passes 802.1Q info in out-of-band struct? ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS miniport driver - expected frame format
    ... Ethernet frames using Ethernet II framing, it adds 4 bytes *between* the ... Source MAC Address and the Type/Length field of the original frame. ... Is this the reason why NDIS passes 802.1Q info in out-of-band struct? ... is to look at the type/length field of the MAC header. ...
    (microsoft.public.development.device.drivers)