Gammaraman
Sat Jul 26 23:34:00 CDT 2008
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@discussions.microsoft.com> wrote in message
> >> news:5AAF0ECD-ED93-48DD-852D-0FD9658E59D4@microsoft.com...
> >> > 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@discussions.microsoft.com> wrote in message
> >> >> news:127016D5-E749-492F-8FB1-0BD898349EA6@microsoft.com...
> >> >> > 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@discussions.microsoft.com> wrote in
> >> >> >> message
> >> >> >> news:9441A736-0520-4748-A2F6-E6C94CACBACB@microsoft.com...
> >> >> >> > 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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>