Outermost VLAN tag is dropped when capture a packet with multiple VLAN tags

[Weihj99]

Describe the bug
When capturing a packet with multiple VLAN tags, the outermost VLAN tag is dropped.

To Reproduce
Steps to reproduce the behavior:

1. Run Wireshark and start packet capture on the target network interface
2. Run the following Python code:

from scapy.all import Ether, Dot1Q, IP, ICMP, Raw, sendp


def send_vlan_icmp(
    iface: str,
    dst_mac: str,
    src_mac: str,
    vlan_id: int,
    src_ip: str,
    dst_ip: str,
) -> None:
    pkt = (
        Ether(src=src_mac, dst=dst_mac)
        / Dot1Q(vlan=vlan_id)
        / Dot1Q(vlan=vlan_id + 1)
        / IP(src=src_ip, dst=dst_ip)
        / ICMP()
        / Raw(load=b"multiple VLAN headers test")
    )
    
    sendp(pkt, iface=iface, verbose=False)
    return pkt


if __name__ == "__main__":
    pkt = send_vlan_icmp(
        # iface="VMware Network Adapter VMnet8",
        # use YOUR OWN network 
        iface="Ethernet 3",
        dst_mac="ff:ff:ff:ff:ff:ff",
        src_mac="00:11:22:33:44:55",
        vlan_id=4,
        src_ip="192.168.10.2",
        dst_ip="192.168.10.1",
    )

3. Check the captured packet in wireshark; you will notice the captured packet has only one VLAN tag (VLAN ID 5), and the outer VLAN tag is missing.
4. If the target network is connected to a port of a Vector VN5640, monitoring the received packets on the VN5640 confirms that the outer VLAN tag is actually present.

Expected behavior
all vlan tags are expected to be captured

Screenshots
packet captured by wireshark

packet captured by canoe

Diagnostic information

• Windows 11 Version 21H2, OS Build 22000.258
• tested on Intel(R) Ethernet Connection (16) I219-V, ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter, Realtek(R) USB GbE Family Controller, VMware Virtual Network Adapter

[dmiller-nmap]

This makes sense to have happened because of the complication of trying to convert packet metadata to a VLAN header. Npcap currently avoids doing so if it thinks the header is already present:

npcap/packetWin7/npf/npf/Read.c

Lines 699 to 720 in fcd2205

	// The packet has VLAN metadata, so it needs to have a 802.1q header
	// Check if we know it's already there.
	if (!pSrcNB->bVlanHeaderInPacket) {
	#define ETHERTYPE_OFFSET FIELD_OFFSET(ETHER_HEADER, ether_type)
	PVLAN_HEADER pVlan = (PVLAN_HEADER)(pNBCopy->Buffer + ETHERTYPE_OFFSET);
	// If it's not already there, add one.
	if (!VLAN_HEADER_VALID(pVlan)) {
	// Shift the packet data down 4 bytes
	RtlMoveMemory(pNBCopy->Buffer + ETHERTYPE_OFFSET + VLAN_HDR_LEN,
	pNBCopy->Buffer + ETHERTYPE_OFFSET,
	pNBCopy->ulSize - ETHERTYPE_OFFSET);
	// Add the VLAN header
	QINFO_TO_VLAN_HEADER(pQinfo, pVlan);
	// Update accounting for the new packet length
	pNBCopy->ulSize += VLAN_HDR_LEN;
	pNBCopy->ulPacketSize += VLAN_HDR_LEN;
	pSrcNB->bVlanHeaderAdded = TRUE;
	}
	// Now we know for sure the header is present.
	pSrcNB->bVlanHeaderInPacket = TRUE;
	}

An easy but incomplete fix would be to additionally check if the VLAN ID in the metadata matches the one in the packet data, but that would have the same issue when the nested header uses the same VLAN ID.

The fix we will go with is to always add the VLAN header back in. As I understand it, there is never a reason why our NDIS filter driver should ever see a VLAN tag as in-band data, so it should be fine to remove this conditional.