Re: NDIS miniport driver - expected frame format
- From: Gammaraman <Gammaraman@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 26 Jul 2008 13:08:00 -0700
Thanks, Peter. I don't quite understand your point.
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.
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.
"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 DSCPIf all you want to do is inspect the IP TOS field, then you'll need to
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?
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 makeNo. The miniport driver (and miniport edge of an IM driver) should be
any assumptions about the framing used by NDIS?
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
- Follow-Ups:
- Re: NDIS miniport driver - expected frame format
- From: Peter
- Re: NDIS miniport driver - expected frame format
- References:
- Re: NDIS miniport driver - expected frame format
- From: Pavel A.
- Re: NDIS miniport driver - expected frame format
- From: Peter
- Re: NDIS miniport driver - expected frame format
- From: Gammaraman
- Re: NDIS miniport driver - expected frame format
- From: Peter
- Re: NDIS miniport driver - expected frame format
- Prev by Date: Re: NDIS - what layer 2 header fields does it fill?
- Next by Date: Re: Mouse driver for XP missing
- Previous by thread: Re: NDIS miniport driver - expected frame format
- Next by thread: Re: NDIS miniport driver - expected frame format
- Index(es):
Relevant Pages
|
