[Winpcap-users] Is an NDIS 5 PacketReceive routine guaranteed to be handed the *full* packet on a system using NDIS 5?

[Guy Harris]

In NPF_tap(), the BPF filter routine is called only with data from the header buffer (HeaderBuffer) if the difference between LookaheadBuffer and HeaderBuffer is equal to HeaderBufferSize (this appears to assume that the packet will be contained in a single buffer in this case, and that the header buffer contains the entire packet), and, otherwise, called with data from the header buffer and the lookahead buffer.

This requires that all the data being checked by the filter be in either the header buffer or the lookahead buffer.

Packet.dll sets the current lookahead size to the maximum lookahead size, presumably to try to ensure that all the data *is* available.

The MSDN documentation for OID_GEN_MAXIMUM_LOOKAHEAD:

	https://msdn.microsoft.com/en-us/library/windows/hardware/ff569599(v=vs.85).aspx

says:

	NDIS 6.0 and later miniport drivers do not receive this OID request. NDIS handles this OID with a cached value that miniport drivers supply during initialization.

	Upper-layer drivers examine lookahead data to determine whether a packet that is associated with the lookahead data is intended for one or more of their clients.

	If the underlying driver supports multipacket receive indications, bound protocol drivers are given full net packets on every indication. Consequently, this value is identical to that returned for OID_GEN_RECEIVE_BLOCK_SIZE.

and the documentation for OID_GEN_CURRENT_LOOKAHEAD:

	https://msdn.microsoft.com/en-us/library/windows/hardware/ff569574(v=vs.85).aspx

says:

	NDIS handles query and unsuccessful set requests for NDIS 6.0 and later miniport drivers. NDIS obtains the information from the miniport driver during initialization and miniport adapter restart. However, NDIS sends valid set requests to the miniport driver.

	For a query, NDIS returns the largest lookahead size from among all the bindings. A protocol driver can set a suggested value for the number of bytes to be used in its binding; however, the underlying miniport driver is never required to limit its indications to the value set.

	If the underlying driver supports multipacket receive indications, bound protocol drivers are given full net packets on every indication. Consequently, this value is identical to that returned for OID_GEN_RECEIVE_BLOCK_SIZE.

Does setting OID_GEN_CURRENT_LOOKAHEAD to OID_GEN_MAXIMUM_LOOKAHEAD guarantee, in all NDIS 6 systems, that the entire packet will be available to the PacketReceive routine?  Somebody reported a problem with WinPcap 4.1.3 on Windows 10:

	https://github.com/the-tcpdump-group/libpcap/issues/455

in which they see traffic from port 80 to the capturing machine if they *don't* have a capture filter of "tcp port 80", but, on Windows 10, but not on Windows 7, *don't* see the traffic if they do have that filter.  One possible cause could be that, in Windows 10, the NPF NDIS 5 driver's ReceivePacket routine isn't getting the TCP header, in which case the filter would reject the packet.

The person who filed the bug said, of the device on which he's capturing, "It's an Ethernet Network, but it's over a Open VPN connection."  I presume he means OpenVPN:

	https://openvpn.net

but I'll ask.