<div dir="ltr">Hi Guy,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 8:12 AM, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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 <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff563246(v=vs.85).aspx">https://msdn.microsoft.com/en-us/library/windows/hardware/ff563246(v=vs.85).aspx</a>). 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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
This requires that all the data being checked by the filter be in either the header buffer or the lookahead buffer.<br>
<br>
Packet.dll sets the current lookahead size to the maximum lookahead size, presumably to try to ensure that all the data *is* available.<br>
<br>
The MSDN documentation for OID_GEN_MAXIMUM_LOOKAHEAD:<br>
<br>
        <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff569599(v=vs.85).aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-us/library/windows/hardware/ff569599(v=vs.85).aspx</a><br>
<br>
says:<br>
<br>
        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.<br>
<br>
        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.<br>
<br>
        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.<br>
<br>
and the documentation for OID_GEN_CURRENT_LOOKAHEAD:<br>
<br>
        <a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff569574(v=vs.85).aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-us/library/windows/hardware/ff569574(v=vs.85).aspx</a><br>
<br>
says:<br>
<br>
        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.<br>
<br>
        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.<br>
<br>
        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.<br>
<br>
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:<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
        <a href="https://github.com/the-tcpdump-group/libpcap/issues/455" rel="noreferrer" target="_blank">https://github.com/the-tcpdump-group/libpcap/issues/455</a><br>
<br>
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.<br></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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:<br>
<br>
        <a href="https://openvpn.net" rel="noreferrer" target="_blank">https://openvpn.net</a><br>
<br>
but I'll ask.<br>
</blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Yang</div></div>