Hi Guy, On Wed, Sep 9, 2015 at 6:25 PM, Guy Harris <[email protected]> wrote:
> > On Sep 8, 2015, at 7:45 PM, 食肉大灰兔V5 <[email protected]> wrote: > > > On Wed, Sep 9, 2015 at 8:12 AM, Guy Harris <[email protected]> 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 > ). > > That's the NDIS 5 version of the documentation for the PacketReceive > function. It would be an ugly incompatibility if NDIS 6's NDIS 5 shims > didn't preserve that behavior, but it's possible that it does. > OK. I thought LookaheadBuffer will always start from the end of HeaderBuffer before this post. I looked twice at the MSDN and found Microsoft never promised this assumption in NDIS 5, so it's reasonable for WinPcap to split this into 2 conditions. Although for NDIS 6, **usually** MAC, IP and TCP headers are carried in the same buffer (I confirmed this in Npcap, also see the figure in: http://codemachine.com/article_ndis6nbls.html), but Microsoft never guarantees it. > > Apparently OpenVPN has both NDIS 5 and NDIS 6 drivers: > > https://community.openvpn.net/openvpn/wiki/CodeRepositories > > I'm guessing that the NDIS 6 driver is being used on his Windows 10 > system; perhaps it does something that the NDIS 6 -> NDIS 5 shim doesn't > handle correctly. > I have a glance at the repo, and I think the NDIS 6 version OpenVPN driver is a NDIS 6 miniport. A miniport is really far away with a protocol (NDIS 5 or 6) (see: http://stackoverflow.com/questions/18257048/ndis-filter-driver-filterreceivenetbufferlists-handler-isnt-called?noredirect=1#comment27011779_18257048). So it's weird that OpenVPN could affect the WinPcap driver. A miniport should be transparent to a protocol. > > > 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). > > I think what it's doing is clearer if it's written as > > if((PUCHAR)LookaheadBuffer != > ((PUCHAR)HeaderBuffer)+HeaderBufferSize) > > which tests whether the lookahead buffer begins immediately after the end > of the header buffer, i.e. that there's really only one buffer; the comment > before it indicates that: > > // > //Check if the lookahead buffer follows the mac header. > //If the data follow the header (i.e. there is only a buffer) a > normal bpf_filter() is > //executed on the packet. > //Otherwise if there are 2 separate buffers (this could be the > case of LAN emulation or > //things like this) bpf_filter_with_2_buffers() is executed. > // > > > I think the caller of ProtocolReceive routine only guarantees that the > HeaderBuffer and LookaheadBuffer together cover till the TCP header. > > Meaning that they will cover the TCP header, or that they only guarantee > that the stuff *before* the TCP header is provided? > Sorry for my english, which I mean NDIS will guarantee the TCP header is contained in LookaheadBuffer (see: http://www.verycomputer.com/5_8593f09f8b078987_1.htm) > > If it's the latter, then: > > > So it's enough to make a decision for a BPF filter. > > ...that's not enough for a BPF filter such as "tcp port 80" that tests > fields in the TCP header. > > If it's the former, even that's not enough for BPF filters that explicitly > test past the end of the TCP header, which *is* possible, and even > supported by the libpcap filter language by using the general expression > mechanism. But that wouldn't cause a problem with "tcp port 80". > You are right, if an application layer filter (like HTTP or FTP) is set, I don't think the current WinPcap implementation will function well, as I didn't see any Microsoft document said they will promise the length of LookaheadBuffer up to application layer. So WinPcap's PacketTransferDataComplete should also do some kind of BPF filter work if NPF_Tap's filter fails with inadequate buffer length. > > I suspect that the NDIS 6 -> NDIS 5 shim in Windows 10 might not be > handling packets provided by the OpenVPN driver - perhaps that driver is > providing packets in a form that the shim can't properly map to something > to hand to an NDIS 5 protocol driver like the WinPcap driver; Npcap is an > NDIS 6 driver, so the shim isn't in the way. > Possible. Cheers, Yang
_______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
