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.
_______________________________________________
Winpcap-users mailing list
Winpcap-users@winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users
