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

[食肉大灰兔V5]

Hi Guy,

On Wed, Sep 9, 2015 at 8:12 AM, Guy Harris <guy at alum.mit.edu> wrote:

> 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.
>

In fact, I didn't quite understand this part when I am doing the porting
job to NDIS 6. AFAIK, like for an Ethernet packet, HeaderBuffer is the
Ethernet header data, and LookaheadBuffer is the data beginning from IP
header. If PacketSize is less than or equal to the given
LookaheadBufferSize, the lookahead buffer contains the entire packet (see
https://msdn.microsoft.com/en-us/library/windows/hardware/ff563246(v=vs.85).aspx).
I don't know why there is a compare between LookaheadBuffer - HeaderBuffer
with HeaderBufferSize. HeaderBuffer can't contain the entire packet (as
there won't be a packet with only Ethernet header and have no content).


>
> 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:
>

I think the caller of ProtocolReceive routine only guarantees that the
HeaderBuffer and LookaheadBuffer together cover till the TCP header. So
it's enough to make a decision for a BPF filter.


>
>         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.
>

I think this is possible. Maybe he should try Npcap to see what happens. As
Npcap doesn't handle a packet in multiple buffers (as a NDIS 6 filter will
always get a whole packet one time).


>
> 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.
>


Cheers,
Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20150909/9cff92e3/attachment.html>