Hi,
We have a NDIS 5.1 miniport driver for Windows XP (WHQL certified) in which
we do NOT support VLAN (802.1P and 802.1Q), i.e. we do not set either of the
flags NDIS_MAC_OPTION_8021P_PRIORITY and NDIS_MAC_OPTION_8021Q_VLAN in query
to OID_GEN_MAC_OPTIONS, neither do we include OID_GEN_VLAN_ID in response to
OID_GEN_SUPPORTED_LIST.
All this is optional as per the DDK and we chose not to support it.
Recently we noticed an issue where we observed that if we happen to receive
a packet having VLAN tag (0x0081) and indicate it to upper layers like any
other packet, then NDIS does not return it back to us, i.e. does not call
MiniportReturnPacket.
However if we set the per packet information (using the macro
NDIS_PER_PACKET_INFO_FROM_PACKET) for InfoType Ieee8021QInfo and strip the
VLAN header from the packet before indicating, then NDIS subsequently
returns it back to us!
So is it necessary even for a non-VLAN aware miniport driver to process VLAN
packets in receive path?
Actually in this case there was no query or set OID for VLAN_ID, so such
packet should ideally be dropped. Is that the right implementation in this
case?
Thanks,
Regards,
Abhijit
Hi,
I found out that only stripping of the VLAN tag is sufficient for NDIS to return the packet back to us.
Btw I would also like to know, if we want to provide support for VLAN then providing only the miniport driver is sufficient or an IM driver is also required (like MUX sample)?
Regards,
Abhijit
What do you mean by “support for VLAN”?
NDIS5x requires only the documented Miniport support for VLAN tagging to ‘support’ VLAN tagging. Vendors provide MUX drivers when they, for example, provide value-added support for creating multiple (virtual) adapters bound to a specific tag so that a single NIC on a tagged port can appear as a (virtual) NIC per VLAN.
So what would you expect to be able to do with your VLAN ‘supporting’ NIC/Miniport?
Good Luck,
Dave Cattley
Thanks for your response.
By “support for VLAN” in the miniport I meant, as I described earlier, to
- set NDIS_MAC_OPTION_8021P_PRIORITY and NDIS_MAC_OPTION_8021Q_VLAN in a query
to OID_GEN_MAC_OPTIONS
- include OID_GEN_VLAN_ID in response to OID_GEN_SUPPORTED_LIST and support it for both QUERY and SET
- insert VLAN tags while sending if NDIS_PACKET_8021Q_INFO is present and strip the VLAN tags while receiving
I intend to do so as NDIS is probably expecting me to strip VLAN tags before indicating packets up and only stripping the tags without doing all of the things given above look like fixing the problem by workaround and not really attending it.
As I don’t intend to provide any kind of extra functionality or value addition, I hope providing a MUX like IM driver is not necessary.
Regards,
Abhijit
> I found out that only stripping of the VLAN tag is sufficient for NDIS to return
the packet back to us.
Very strange. Is the machine clean of all sorts of antiviruses, “network enhancers” and so on? Is it by chance Win7 / 2008?
–pa
> Very strange. Is the machine clean of all sorts of antiviruses, "network
enhancers" and so on? Is it by chance Win7 / 2008?
Well, not really, the machine is in the field with some softwares installed. This issue is not generic too. It works properly in some setups but fails on a particular network. Both the working and failing networks have VLAN traffic but not of the same kind.
It would also help to note that another network card in the failing setup too doesn’t process any VLAN packets but still works properly.
The issue with our driver however is definitely related to VLAN as it works (ReturnPacket gets called) when we strip VLAN tags.
The OS is XP SP3. Due to some constraints we could not check with Vista/Win7.
wrote in message news:xxxxx@ntdev…
>> Very strange. Is the machine clean of all sorts of antiviruses, “network
>> enhancers” and so on? Is it by chance Win7 / 2008?
>
> Well, not really, the machine is in the field with some softwares
> installed. This issue is not generic too. It works properly in some setups
> but fails on a particular network. Both the working and failing networks
> have VLAN traffic but not of the same kind.
>
> It would also help to note that another network card in the failing setup
> too doesn’t process any VLAN packets but still works properly.
> The issue with our driver however is definitely related to VLAN as it
> works (ReturnPacket gets called) when we strip VLAN tags.
>
Do you report the max. packet size and MAC header size correctly (including
or excluding 2 bytes for the 802.1p/q tag)?
–pa
wrote in message news:xxxxx@ntdev…
>>> Very strange. Is the machine clean of all sorts of antiviruses, “network
>>> enhancers” and so on? Is it by chance Win7 / 2008?
>>
>> Well, not really, the machine is in the field with some softwares
>> installed. This issue is not generic too. It works properly in some setups
>> but fails on a particular network. Both the working and failing networks
>> have VLAN traffic but not of the same kind.
>>
>>It would also help to note that another network card in the failing setup
>>too doesn’t process any VLAN packets but still works properly.
<…excess quoted lines suppressed…>
>Do you report the max. packet size and MAC header size correctly (including
>or excluding 2 bytes for the 802.1p/q tag)?
Yes, we are responding to following OIDs with 4 bytes (VLAN tag) lesser than what we were reporting earlier:
OID_GEN_MAXIMUM_LOOKAHEAD, OID_GEN_MAXIMUM_FRAME_SIZE, OID_GEN_MAXIMUM_TOTAL_SIZE, OID_GEN_TRANSMIT_BLOCK_SIZE, OID_GEN_RECEIVE_BLOCK_SIZE
Ref: http://msdn.microsoft.com/en-us/library/ff564208(v=VS.85).aspx
wrote in message news:xxxxx@ntdev…
> wrote in message news:xxxxx@ntdev…
>>>> Very strange. Is the machine clean of all sorts of antiviruses,
>>>> “network
>>>> enhancers” and so on? Is it by chance Win7 / 2008?
>>>
>>> Well, not really, the machine is in the field with some softwares
>>> installed. This issue is not generic too. It works properly in some
>>> setups
>>> but fails on a particular network. Both the working and failing networks
>>> have VLAN traffic but not of the same kind.
>>>
>>>It would also help to note that another network card in the failing setup
>>>too doesn’t process any VLAN packets but still works properly.
> <…excess quoted lines suppressed…>
>
>>Do you report the max. packet size and MAC header size correctly
>>(including
>>or excluding 2 bytes for the 802.1p/q tag)?
>
> Yes, we are responding to following OIDs with 4 bytes (VLAN tag) lesser
> than what we were reporting earlier:
> OID_GEN_MAXIMUM_LOOKAHEAD, OID_GEN_MAXIMUM_FRAME_SIZE,
> OID_GEN_MAXIMUM_TOTAL_SIZE, OID_GEN_TRANSMIT_BLOCK_SIZE,
> OID_GEN_RECEIVE_BLOCK_SIZE
> Ref: http://msdn.microsoft.com/en-us/library/ff564208(v=VS.85).aspx
>
Ah, sorry. 4 bytes of course.
So, is there a chance that when you do not remove the tag,
OID_GEN_MAXIMUM_FRAME_SIZE is greater than 1500
or OID_GEN_MAXIMUM_TOTAL_SIZE greater than 1514?
–pa
So, is there a chance that when you do not remove the tag,
…
IIRC if the tag is not stripped, not very much is going to work as the
packet will be seen as having the Ethertype of the tag and not of the actual
payload. By not work what I mean is that protocols are not typically
looking for all of the possible MAC header variants that while ‘legal’ on
the wire are just not typically present in NDIS packets (because the
VLAN/Priority tag *information* is carried OOB in NDIS) and so protocols are
likely to just ignore the packet on receive as ‘not theirs’.
Good Luck,
Dave Cattley
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
My miniport has option to shoot packets up with vlan tag in-band
because we have use case for that. I don’t remember seeing your
problem.
On Tuesday, May 31, 2011, Abhijit Mirajkar wrote:
> Hi,
>
> We have a NDIS 5.1 miniport driver for Windows XP (WHQL certified) in which
> we do NOT support VLAN (802.1P and 802.1Q), i.e. we do not set either of the
> flags NDIS_MAC_OPTION_8021P_PRIORITY and NDIS_MAC_OPTION_8021Q_VLAN in query
> to OID_GEN_MAC_OPTIONS, neither do we include OID_GEN_VLAN_ID in response to
> OID_GEN_SUPPORTED_LIST.
> All this is optional as per the DDK and we chose not to support it.
>
> Recently we noticed an issue where we observed that if we happen to receive
> a packet having VLAN tag (0x0081) and indicate it to upper layers like any
> other packet, then NDIS does not return it back to us, i.e. does not call
> MiniportReturnPacket.
> However if we set the per packet information (using the macro
> NDIS_PER_PACKET_INFO_FROM_PACKET) for InfoType Ieee8021QInfo and strip the
> VLAN header from the packet before indicating, then NDIS subsequently
> returns it back to us!
>
> So is it necessary even for a non-VLAN aware miniport driver to process VLAN
> packets in receive path?
> Actually in this case there was no query or set OID for VLAN_ID, so such
> packet should ideally be dropped. Is that the right implementation in this
> case?
> Thanks,
>
> Regards,
> Abhijit
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> My miniport has option to shoot packets up with vlan tag in-band
because we have use case for that.
Hi Calvin,
Is this option implemented just by not reporting NDIS_MAC_OPTION_8021Q_VLAN & NDIS_MAC_OPTION_8021P_PRIORITY capabilities?
Regards,
–pa