Re: Is the MUX Sample Drive Incorrect?

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

Yes, your assumption seems valid. Let me add some information on the
history of VLAN support in NDIS here:

VLAN support was added in NDIS 5.1, i.e. in Windows XP. Earlier
versions of NDIS or the OS did *not* support VLAN tagging directly.
NDIS 5.1 supports VLAN tagging in the OOB (out-of-band) information of
an NDIS_PACKET.

The MUX sample allows VLAN support even for earlier OS versions, namely
Windows 2000. IIRC, MUX does so by simply adding/removing the VLAN tag
information to/from the packet (frame) itself. The NDIS 5.1 VLAN
support mechanism is not used here.

I am not sure whether the MUX sample makes any distinction between NDIS
versions wrt VLAN support. Somebody correct me if I am wrong here.

Anyway, the important part is that there are NIC miniports out there
that do support VLAN tagging, while others don't. I have even seen an
Intel miniport recently that silently (!) removes VLAN tags on all
received frames. We thus had to download a special driver from Intel
and set a special registry key so the driver does no longer remove the
VLAN tag. (This is kind of ironical, right? I need a special driver to
*not* use a certain feature...)

So I suggest you first make sure the NIC miniport actually works as you
expect. Simply start any network sniffer like the MS Network Monitor,
Ethereal, or just any other. Then make sure you actually see VLAN
tagged frames being received on the physical (!) NIC.

For a short overview on the history of NDIS see also:


http://msdn.microsoft.com/library/en-us/network/hh/network/103prog_123c3b1d-c431-4829-9943-fd060d3ebe07.xml.asp

HTH, Stephan
---
Brent J. Gunning wrote:
> According to MSDN here
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/network/hh/network/204_802p_7a58dda8-5561-496c-bcac-5ac7b0bdac2e.xml.asp),
> on receive miniport drivers are supposed to remove the tag header vlan
> information and place it into the OOB data if the configured VLAN ID of
> the NIC is 0 and the packet contains a tag header. Therefore, if a
> packet was being received, it will have to go through the miniport
> driver before ever reaching the MUX driver --- right? So wouldn't the
> VLAN information be stripped out of the tag header and the MUX driver
> would never see it?

.

Relevant Pages

  • Is stripping the VLAN header mandatory in NDIS 5.1 ?
    ... which we do NOT support VLAN, ... layers like any other packet, then NDIS does not return it back to us, ... So is it necessary even for a non-VLAN aware miniport driver to ...
    (microsoft.public.development.device.drivers)
  • Re: Is stripping the VLAN header mandatory in NDIS 5.1 ?
    ... I found out that only stripping of the VLAN tag is sufficient for NDIS ... to return the packet back to us. ... then providing only the miniport driver is sufficient or an IM driver ...
    (microsoft.public.development.device.drivers)
  • Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
    ... was enabled when a vlan device was configured. ... think stripping should be enabled. ... the tg3 driver was trying to disable VLAN tag stripping ... drivers have been converted to the new vlan interfaces I'll be ...
    (Linux-Kernel)
  • Re: urlsnarf woes
    ... That has removed the VLAN tag (as verified by ... If I run urlsnarf on eth0 and run up a browser, ... Securing Apache Web Server with thawte Digital Certificate ...
    (Security-Basics)
  • expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
    ... the complete packet with vlan tag included as the driver simply calls ... thing vlan tag included and sends this through the socket. ... The packet socket gets everything including the vlan tag as I'd ...
    (Linux-Kernel)