Bug 1854416

The striping of the tag is the expected result in Windows:
*PriorityVLANTag (standard Window keyword for NICs) documentation states (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords):

> The miniport driver should remove the 802.1Q header from all receive packets regardless of the *PriorityVLANTag setting. If the 802.1Q header is left in a packet, other drivers might not be able to parse the packet correctly.
> If the Rx flag is enabled on the receive path, the miniport driver should copy the removed 802.1Q header into OOB.
> Otherwise, if the Rx flag is disabled, the miniport driver should not copy the removed 802.1Q header into OOB.

Therefore we are removing the tag and setting VLAN ID in the metadata passed to the upper layers.

Also, VLAN ID 0 means pass all packets.

So if you want the driver to receive\send packets for specific VLAN, set VLAN ID in the advanced tab.

> The striping of the tag is the expected result in Windows:
> *PriorityVLANTag (standard Window keyword for NICs) documentation states (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords):

Well, this is very surprising, thanks for sharing.

If I correctly read it, Microsoft's documentation states that the VLAN ID should be put in a out-of-band data buffer to further processing (including being dropped) from the upper layers; however, the packet is never dropped because a running DHCP server tries to offer an IP address to the rouge client. I am not a Windows driver developer, but this sounds bad: a rouge packet arriving with an unknown VLAN ID should *not* be passed to listening sockets/ports.

It's telling that the Intel e1000 driver (virtualizing a real server-grade adapter) will *not* pass unauthorized tagged packets to user applications.
On the other hand, an e1000e (notice che final 'e'), providing a client-like Intel gigabit adapter, behaves as virtio-net (stripping the VLAN ID).

> Also, VLAN ID 0 means pass all packets.

All *untagged* packets - yes.
All packets (including ones tagged with unknow VLAN) - I am not sure, especially considering that the VLAN tag is stripped and the packet can be received by processes it was never intended for.

> So if you want the driver to receive\send packets for specific VLAN, set VLAN ID in the advanced tab.

Sure, but it needs to be done on each Windows guests, which can be tedious.
Regards.

I will take an additional look.


For now, you can script the changes for the guest with PowerShell (set-netadapter):
https://docs.microsoft.com/en-us/powershell/module/netadapter/set-netadapter?view=win10-ps

And driver setting change can be scripted with a tool we supply with the installation: https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/NetKVM/CoInstaller/readme.doc

Which Windows version you're using?

It looks like there the VLAN is explained better:
http://woshub.com/configure-multiple-vlan-on-windows/

(In reply to ybendito from comment #5)
> Which Windows version you're using?

I tried it on both Windows Server 2019 and Windows 10 20.04

Then the comment #6 will be useful for Server 2019. According to the link client OS does not have built-in support for VLAN splitting above the miniport.

Closing based on comment #6 and comment #8.

Sorry, but I fail to understand how comment #6 explains the issue described here (which is thoroughly described in comment #1 and comment #2)
Am I missing something?

(In reply to g.danti from comment #10)
> Sorry, but I fail to understand how comment #6 explains the issue described
> here (which is thoroughly described in comment #1 and comment #2)
> Am I missing something?

Hello,

1. In the link provided in comment #6 paragraph "How to Configure Multiple VLANs in Windows Server 2016" you can see that VLAN ID 0 in the configuration is used to receive all packers in order to later redirect them to a specific adapter.

2. Also nowhere in other documentation, it is said that the configuration of VLAN 0 should drop other VLAN tags.
What is say at best is: "The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority (in PCP and DEI fields) and is referred to as a priority tag.", but this is for the data in the packet."

3. e1000 can hardly be related as a reference, because this is a very old device (not sure if it is even supported on newer Windows versions).

4. Another point - our behavior passes MS WHQL tests that are testing vlan\priority tagging.

Best regards.
Yan.

(In reply to Yan Vugenfirer from comment #11) 
> 1. In the link provided in comment #6 paragraph "How to Configure Multiple
> VLANs in Windows Server 2016" you can see that VLAN ID 0 in the
> configuration is used to receive all packers in order to later redirect them
> to a specific adapter.

First, thank you for taking the time to reply.
You are right, I missed how the VLAN tag was specified to on team interface.

> 2. Also nowhere in other documentation, it is said that the configuration of
> VLAN 0 should drop other VLAN tags.
> What is say at best is: "The reserved value 0x000 indicates that the frame
> does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a
> priority (in PCP and DEI fields) and is referred to as a priority tag.", but
> this is for the data in the packet."

Ok, but I find strange (if possible) that the packet is accepted being stripped of the VLAN tag *only*
Both virtio-net on Linux and e1000 on Windows do not drop the packet, but at the same time do not drop the VLAN tag neither. In this manner, no higher-level application can see the packet unless it put the interface in promiscuous mode.

The current virtio-net Windows driver, instead, accept the packet (as I expected) but remove its VLAN tag. This means that other application listening on broadcast (eg: DHCP client) actually see (and consume) the packet. For example, a DHCP client can respond to a DHCP offer of a server whose packets are tagged with another VLAN ID.

Note that I am not saying you are wrong, quite the opposite. But I find this behavior quite confusing.

> 3. e1000 can hardly be related as a reference, because this is a very old
> device (not sure if it is even supported on newer Windows versions).

As far I can see, e1000 is supported and WHQL certified on Windows 2019/2016

> 4. Another point - our behavior passes MS WHQL tests that are testing
> vlan\priority tagging.

True, but the same is for e1000 - which show a different behavior.

Regards.

(In reply to g.danti from comment #12)
> (In reply to Yan Vugenfirer from comment #11) 
> > 1. In the link provided in comment #6 paragraph "How to Configure Multiple
> > VLANs in Windows Server 2016" you can see that VLAN ID 0 in the
> > configuration is used to receive all packers in order to later redirect them
> > to a specific adapter.
> 
> First, thank you for taking the time to reply.
> You are right, I missed how the VLAN tag was specified to on team interface.
> 
> > 2. Also nowhere in other documentation, it is said that the configuration of
> > VLAN 0 should drop other VLAN tags.
> > What is say at best is: "The reserved value 0x000 indicates that the frame
> > does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a
> > priority (in PCP and DEI fields) and is referred to as a priority tag.", but
> > this is for the data in the packet."
> 
> Ok, but I find strange (if possible) that the packet is accepted being
> stripped of the VLAN tag *only*
> Both virtio-net on Linux and e1000 on Windows do not drop the packet, but at
> the same time do not drop the VLAN tag neither. In this manner, no
> higher-level application can see the packet unless it put the interface in
> promiscuous mode.

As I mentioned previously, this is from MS documentation: 
"The miniport driver should remove the 802.1Q header from all receive packets regardless of the *PriorityVLANTag setting. If the 802.1Q header is left in a packet, other drivers might not be able to parse the packet correctly."
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/enumeration-keywords

So we don't have a choice but to remove the tag and put it into meta data.

> 
> The current virtio-net Windows driver, instead, accept the packet (as I
> expected) but remove its VLAN tag. This means that other application
> listening on broadcast (eg: DHCP client) actually see (and consume) the
> packet. For example, a DHCP client can respond to a DHCP offer of a server
> whose packets are tagged with another VLAN ID.
> 
> Note that I am not saying you are wrong, quite the opposite. But I find this
> behavior quite confusing.
> 
> > 3. e1000 can hardly be related as a reference, because this is a very old
> > device (not sure if it is even supported on newer Windows versions).
> 
> As far I can see, e1000 is supported and WHQL certified on Windows 2019/2016
> 
> > 4. Another point - our behavior passes MS WHQL tests that are testing
> > vlan\priority tagging.
> 
> True, but the same is for e1000 - which show a different behavior.
> 
> Regards.

Best regards,
Yan.

How to Configure Multiple VLANs in Windows Server 2016(In reply to g.danti from comment #10)
> Sorry, but I fail to understand how comment #6 explains the issue described
> here (which is thoroughly described in comment #1 and comment #2)
> Am I missing something?
I suggest to open the http://woshub.com/configure-multiple-vlan-on-windows/
Scroll down to "How to Configure Multiple VLANs in Windows Server 2016" and try follow the recommendation.